I'm in the UAT phase of a project I am trying to configure my board using custom columns so I can easily track the progress of bugs through their life cycle. It seems like this is possible, but yet it doesn't quite work.
The new, active & resolved columns all show bugs - however the other columns do not, even though I have mapped them to valid statuses. I can run a query and can see there are plenty of bugs currently set to "In QA".
Why aren't they appearing in the list?
Am I going about this wrong? Is there another way to get this kind of view?
It’s mainly caused the Kanban board filter cards condition hide some work items which not meet the conditions. So in Kanban board -> click filter cards -> make sure all filter cards are not selected.
Such as If all filter cards not selected, the Kanban board will shows all user stories and bugs. If Iteration select all, there won’t show all work items.
Also please check the query conditions are correct or not as the issue said.
Create and customize in inherited processes:
In Process Tab https://account.visualstudio.com/_admin/_process, create inherited process from Agile template.
Click Bug for the inherited process, in the States Tab, add new states in Resolved category so that the bug process is: New -> Active -> Resolved -> In QA -> QA Approve -> In UAT -> Closed.
In kanban borad -> settings -> columns -> set IN QA column bug state as In QA, QA Approve column bug state as QA Approve, In UAT column bug state as In UAT -> save.
Related
We rolled ADS out as our main development platform a few months ago and generally have be working pretty well in it. However, one of the things I've noticed is I (project admin) am unable to set Epics or Features to a state outside of "New", "Close", or "Removed". The feature I added a picture of has 2 child user stories - one of which is "Active" and one which is "Resolved". It also has a parent Epic which is set to "new" because I'm unable to change the state of that one to Active either. As far as I can tell, I've added all the information I can to the feature, and based on the Microsoft documentation it appears I should have more states available but can't figure out what I'm missing.
Any help would be appreciated!
1 - Are you sure that you have defined state which you want to use in your Process definition?
Process name that you currently use in your project can be found here https://dev.azure.com/MyOrganizationName/ProjectName/_settings/
Process states definition can be found here https://dev.azure.com/MyOrganizationName -> Organization Settings -> Boards -> Process -> -> <Select 'Feature' work item> -> States
2 - Maybe someone has restricted state transition creating new rule for your process? Like in this example?
Documentation regarding this can be found here
https://learn.microsoft.com/en-us/azure/devops/organizations/settings/work/apply-rules-to-workflow-states?view=azure-devops#restrict-state-transitions
I'm trying to setup azure devops test project and introduce it to our team. So I created test user stories and related tasks. I also created test sprints (10 work days each) starting with 2021-07-19. So far so good. Taskboard contains tasks and user stories, for test purposed I "finished" some work yesterday. Backlog tab seems to be working well, remaining work and work details works as expected too. Capacity tab is filled.
But once I enter Analytics tab with burndown trend it seems to be empty. No task nor user stories. Did I miss something? I tried all tutorials and all seems to be set correctly. See pictures below.
Do you have any advice or hints?
Thanks!
EDIT: Legacy burndown graph in dashboard works fine.
After a while I found solution. My test project contains only user stories and related tasks and thus the structure is obviously User story -> Tasks. However in the project setting -> Boards - Team configuration I left checked also Features checkbox. Based on that setting expected structure is Feature -> User stories -> Tasks which I haven't. So once I unchecked Features checkbox all started to work as expected. I might be useful for others as well.
I am using Area Path in Azure DevOps for categorization rather than breaking into separate Teams. So I can't see all the Work Items underneath the Default Backlog. I go into Settings and choose "Include Sub Areas" and I get the following Warning:
Are you sure you want to include sub-areas?
You have selected the root area path as your team's work area. This
causes two things to happen:
All work items that appear on any team backlog will also appear on
your team's backlog.
All work items under this area path will be updated, which might
impact the performance of your server until the changes are complete.
Are you sure you want to do this? If not, choose Cancel, and the
change will not be made.
#1 is what I want, but what are the implications of #2? What is updated on the Work Item? Will the Assigned To user be emailed of the change?
For #2. The items will be stackranked again to define the backlog order for all work items in the selection. I've seen instances that had millions of work items and the recalculation of the backlog priority field and mapping to your team's custom board columns may take a while in that case.
This field is excluded from the standard email notifications.
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.
I still didn't get it.
Where do complete backlog stays if we have to plan for new sprint and pick items from backlog. Like I can see stories/features but what about all bugs/issues, where they can be seen?
I don't want to search for all items in queries/work items. How can I bring all work items in backlog?
Sounds like you're using the Agile template, which doesn't put everything on the product backlog by default. You can edit the backlog settings to put the bug workitem on the backlog. You can find this setting in the Backlog customization screen, as long as Bug is configured to show up as a requirement, it should show up on the product backlog:
Since issues follow a completely different workflow, they cannot be placed on the product backlog. I would guess that they're being used as something else than what they were meant for. But you'd have to help me with additional information. The Issue work item type is the scrum equivalent of an Impediment. Anything that is blocking the team from progressing effectively. These aren't part of the work that goes into the product and are not managed on the same list.
If you're using the Issue work item as a different kind of Bug/Defect then I recommend either creating a custom field on bug to signal the bug type or create a new work item type that is a copy of bug to start with, that way it starts out with all the fields required for it to show up on the backlog.