“Working with Bugs” in Azure DevOps
When I say “Working with Bugs”. I’m specifically talking about the Team Configuration setting in Azure DevOps.
Where is this configured in Azure DevOps?
You can find “Working with Bugs” in Team Settings. Which you can access from the gear on a team’s backlog and Kanban board or in Team configuration under Project Settings.
This team setting only shows up in Team Projects created from the Agile, Scrum or CMMI templates. The Basic template does not have a bug work item type and therefore does not apply.
One other point I should mention: You need to be a Team Administrator or Project Administrator to be able to change this setting.
Working with Bugs
As I mentioned this is a Team Configuration Setting. By changing this setting each team can work with bugs in a different way.
Why is this even an option you might ask?
Depending on the team you may have different ideas on how to deal with bugs, lets look at a couple of scenarios.
Scenarios
- Some teams want to raise a bug against a requirement and deal with it as it relates to the requirement. Therefore they might make the bug a child of the requirement and only complete the requirement once all the tasks and bugs are closed.
- Other teams may find a bug during the sprint and resolve it before the end of the sprint. So why create a new work item when comments on the requirement, and internal team discussions will do.
- What if the bug is not fixed during the sprint? Perhaps there is a good workaround and it’s more important to deliver the requirement with the bug, then holding up the requirement. You may want to add a new work item so you don’t forget about this bug. The new work item could be a bug or even a new requirement.
- Perhaps the bug was found in production or outside the sprint by someone else. In both these cases the team likely wants something added to the backlog and prioritized with other upcoming stories. This could also be a bug or a requirement.
- Some companies like to track separate metrics on bugs, therefore some of the above scenarios will not do.
These are just a few things to think about when deciding how your team wants to work with bugs.
What are my options?
In Azure DevOps you have three options for “working with bugs”.
- Bugs are managed with requirements.
- Bugs are managed with tasks.
- Bugs are not managed on backlogs and boards.
Each team can select one of these options to configure Azure DevOps to help them manage bugs the way they want.
Lets take a look at what each setting does, to help you choose.
Bugs are managed with requirements
When you choose this option bugs will be assigned to the Requirement Category and therefore show up in your team’s backlog and Kanban board.
And now you can…
- Add bugs right on the backlog and Kanban Board
- prioritize bugs in the backlog along with requirements.
- estimate Bug effort for forecasting.
- include Bugs in Velocity charts and Cumulative Flow Diagrams,
- use the Forecast tool to support sprint planning
- drag and drop bugs onto Planning pane to assign bugs to a sprint
- view Bugs on a Delivery Plan.
- view bugs on Sprint Task Board left column along with Requirements.
You may want to add tasks as children of the bug to show the work required to fix. This is help with sprit capacity planning.
Because they now show up on your team’s Kanban Board, you need to configure your Kanban board so each board column maps to a Bug State.
Bugs are managed with tasks
When you choose this option bugs are assigned to the Task Category which means they will show up on your Sprint Task Board with tasks, where you can update their status the same as tasks. In this scenario you would estimate work for bugs similar to tasks.
You will also be able to add bugs to the Team’s Sprint Task Board. Which will be automatically linked as a child to the requirement.
Depending on your process template this may add extra columns to your Task Board to accommodate the extra states of the bug work item type in your process.
Note: You could change the states in the process template to simplify this. Keep in mind that will affect all the teams in the Team Project using that process template, and it’s possible they are not all managing bugs the same way.
Bugs are not managed on backlogs and boards
When this option is selected bugs will not show up on any boards or backlogs anywhere in Azure DevOps. If you still want to track Bugs you would just use work item queries and dashboards instead.
Bugs seem to have extra fields
You may have also noticed the bug work item type in each of the process templates (Scrum, Agile, CMMI) has fields from the Requirement (Effort, Story Points, Size) and the Task (Remaining, Original Estimate, Completed).
Having all of these on the bug help to facilitate switching the Bug between Requirement Category and Task Category.
If you decide to treat bugs like Requirements you can use Effort, Story Points, or Size to help size the Bug.
If you decide to treat bugs like Tasks you can use Remaining, Original Estimate, and Completed to estimate the amount of work for the bug.
