If I create a new project and select the Agile process, my user stories will be grouped in iterations Eg "MyProject/Iteration 1".
However, If I create the project using Basic process and after the project has been created, changes the process to Agile I can group my user stories by Sprint Eg "MyProject/Sprint 1".
The latter is what I want, however as the process was set to Agile when the project was created (not by me), I'm trying to figure out how to change it to use Sprints as default?
Side note:
I cannot create a new project as I lack privileges
I cannot create a new process as I lack privileges
I cannot change to another process because I've already created a bunch or user stories
Although I can create sprints manually, I want it to be default.
Thank you!
From this document, we can know that iteration and sprints represent the same concept in the agile process.
Define Iteration Paths (aka sprints) and configure team iterations
So if you want to visually use Spirits as the default, you can add a new iteration named Spirit in team configuration, or change the name of the existing iteration to the Spirit style. Then set it as Default iteration. As shown in the following figure:
Because your current project is already Aglie process, the initial display must be MyProject/Iteration 1. If you want to display like MyProject/Sprint 1, you have to modify it later.
There are two ways to change the display: changing the process or manually modifying it.According to your Side note, obviously neither is feasible.
If you really want Spirits as default in agile progress project without any manual modification,you could submit a feature request in our Develop Community site. Our PM and product team will kindly review your suggestion.
There is no way to do this without changing the Process of your project.
Related
I want to restore the state my project was in 11/10/2021 into another temporary project (not the one I am currently using), so I can only grasp the order of work items from Backlogs from Boards for that day. I did not delete the project. I just changed the Area Paths for Teams and the order of work items changed. I just want to have a reference in a separate temporary project, so I can compare work items order between them and restore correct one to the actual backlog.
Doing something like this is going to be quite tricky, I think that the closest you will come to doing this will be to create a new project and then try to use the open-source migration tools at https://marketplace.visualstudio.com/items?itemName=nkdagility.vsts-sync-migration. We used an earlier version of this for an Azure DevOps carveout from another tenant, and it worked well, but we didn't have your "restore-to-point-in-time" use case.
I think that what you're going to need to do is use the ReplayRevisions on the WorkItemMigration class, and then you're probably going to need to write some custom WIQL to get only what you're looking for. It's even conceivable you might need to extend this to get the functionality you want.
I have problem with configuration of AzureDevOps process.
My goal is simply automate work items - when work item changes state to done or is in state done on certain board I want to transfer it on other board.
I tried to achieve this by applying custom rules in my organization. Example:
I navigate to Organization Settings, select Process then I select process from list (is inherited from Scrum parent). Then I select bug (for example) and go to rules tab.
Here is screen of my configuration
Both Board no.1 and Board no.2 exist as Team Projects. I've added clearing assign to field and this one works properly.
I wondering if there is much easier way to automate moving work items through boards or team projects on status change.
I wondering if there is much easier way to automate moving work items
through boards or team projects on status change.
For this issue, I am afraid there is no easier way to achieve this requirement. Azure Devops has provided a built-in custom rule function to achieve this. This is already a very easy way.
In addition, we can also achieve this through the azure logic app, but this needs to be set in the azure portal. I don’t think it will be more convenient than custom rules.
To move work items to another project, you must be a member of the Project Administrators group or be granted explicit permissions to move work items.
Sorry if this isn't the right place for this, but all the devops question I see on stack exchange seem to be in stackoverflow.
I've begun working with Azure DevOps, and something I'm noticing is that managing items becomes more cumbersome as I add in more bugs, stories, etc... I'm searching for a way to be able to manage and prioritize these items more easily, and I was wondering if it's possible to have multiple backlogs. Say one for bugs, then one for enhancements, one for support tickets. The issue I'm running into is that we only have one team of developers, so ideally this would all be housed under one team so all these items can be dealt with in a single team's sprint instead of a sprint for each team.
Initially I thought that queries might be a viable option, but when creating them I quickly learned that I cannot reorder items. So that ended that idea.
I also considered just viewing the backlog with a filter to only show what I'm looking for, but that too does not allow me to reorder items easily. It looks like I can drag n drop them, but that doesn't work. I can open the ellipsis menu and choose "move to position", but that's far too clunky of a solution when you have many work items. I also sometimes get conflict errors when trying to move them in that manner.
So I keep coming back to the idea of multiple backlogs for a single team. Is this possible? I don't really see anything in the documentation, and I don't even know if this is considered best practice? Any insights are greatly appreciated.
Sounds like you have tried the out the most obvious ways of filtering and searching for workitems in the backlog and on the boards.
What you can setup is an hierarchy of area paths and (sub)teams to allow for filtered view of the backlog.
Consider the following structure of area paths
ProjectName
- Bugs
- Enhancements
- Tickets
Then you create 4 teams, each corresponding to one node in the Area Path tree (make sure to tick the box include children for all of them). As you now have 4 teams you also get 4 backlogs. The top level team that maps to ProjectName will contain the full backlog (equivalent to what you have now). The other three will only show workitems under their respective area path. You can now use those 3 teams to view filtered versions of the backlog (or boards), but still maintain a single backlog on top level.
As Iterations are defined per project, and are shared across teams, you can continue with one set of iterations and add them to all teams, making them shared.
By this setup any team member can jump between the different subteams to view their preferred filtered version of the backlog (or the complete backlog on the root team)
This feels kinda hackish, setting up new "Teams" just to filter the backlog and whether this is considered best practice or not isn't straightforward to answer. Generally an Agile team should have one backlog and prioritize it as a whole but one could argue that the top level combined backlog fills that purpose and the sub backlogs are used for easier management and for visualizing only parts of the backlog. After all Agile is not about tools it is about being productive.
As danielorn's answer, you can set up multiple iterations. But you don't need to set up multiple teams, you can just use your currently team.
You can try the following steps to see whether this method can fit your requirement.
Step 1. Go to Project Settings -> Boards/Project configuration, create some new child Iterations of your project. In your case, you can leave out the start and end dates of the iteration. Just like this:
Step 2. Go to Boards/Backlogs -> View Options (top right corner) -> Choose "Planning".
Step 3. Click "New Sprint" in the Planning Side Pane, add the Iterations you have created in step1 to the Planning. (Of course, you can skip step 1 and directly create new iterations here, but the iterations you create here must have start and end dates.)
Step 4. Drag the work item to the corresponding Iteration. Then click the iteration, you will see a "new" Backlog that only has work items of this iteration.
My team is currently using the CMMI board in Team Services and we would like to switch to the Agile board. I was told we can't just change the template, but I can't figure out how to export all of our open tickets to a new board. How do I easily change our team's board. Thanks!
At the moment this is technically not possible. When you choose a Process, during project creation, you can't change it to a new parent later. So you pick CMMI, or Agile or Scrum and later you can only change to a derived template.
What you can do though, is create an inherited process template and customize it until it looks and feels the same as another process template. It's quite a bit of work, but doable.
It is expected that changing from one base template to another will be added somewhere in the future. But at the moment it's not showing up on the TFS/VSTS feature timeline.
There is no easy import/export option either, though there are a few tools, like VSTS Sync Migration Tool that can copy over work items and map them to a new structure. I'll probably just be as much work as creating an inhertited process though.
My team is looking to migrate many of our tools (SCM, bug-tracking, builds, testing) to TFS. We're considering moving each system in stages. For example, move source control first, bug/feature tracking next, etc...
Since we have to choose a process template to use source control (or anything in TFS) how locked in are we with the decision? I'm looking to avoid having to create another project later (or is that not as bad as I think it would be?).
I know I can in theory customize everything the process template configures after the fact (right?), but how feasible is this in practice?
Here is how I see things happening:
We migrate our source code. We choose Microsoft's CMMI template.
We create a new work item (or check-in note) that is a simple link to our legacy bug tracking system.
We work for awhile.
We wait until the powers that be (we're a decent sized software company) to work out a new TFS development workflow. This may be a simple collection of new work items or an entirely new template that configures all sorts of stuff.
We try to migrate our TFS project to this new system without loosing our history.
Will we be sorry we didn't just wait until all these decisions were finalized before using TFS?
So, you are right to think about your process template as there is a certain amount of "lock-in" however it isn't too severe. It's like you are stuck to your process template with honey rather than super glue.
Personally, I would start with the MSF Agile template. It is much lighter weight and contains less work items - so you more likley to want to add things to it (very easy in TFS, very well supported) rather than take them away (more complicated and not entirely satisfactory).
However, if the power's that be decide to go down an uber process definition process and magically come up with a new process template in 12 months time that they want you to use then it isn't completely lost. If you find that you want to create a brand new Team project, as long as it is on that server (or Project Collection in TFS 2010) then you can either branch your code over to the new team project (which means that history is somewhat obscured in current versions of the TFS clients) or you can create a new Team Project with an empty folder for source control and then move the child folders over from the old team project to the new one. This will preserve history perfectly as TFS maintains history for moves on the same TFS instance. Your work items from before the move will be stuck over in the old process template though and you'll need to decide if you want to copy them or just leave them to get closed out naturally.
Obviously, by actually using TFS for 12 months on real projects, when the powers that be come knocking you are also going to be in a much better position to know what you want your shiny new process template to look like - and I've often found that this is an excercise that just never happens and most people are happy tinkering around the edges of MSF Agile or pick something more prescriptive like Scrum For Team System.
Hope that helps,
Martin.