Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to handle work associated with Bugs in Azure DevOps

Tags:

azure-devops

We're beginning an effort to move to Azure DevOps (ADO). We've used it in the past (when it was VSTS). One of the things that seemed a bit odd was that we would work work items of type 'Bug' directly, associating the work directly with the Bug.

It seems implied in some of the documentation that a Bug should not be worked directly. Instead, child 'Task' items are created under the bug.

I am unable to find documentation in this regard. Does documentation exist in this regard? What are best practices for working bugs in ADO?

like image 633
GaTechThomas Avatar asked Mar 13 '19 15:03

GaTechThomas


1 Answers

Originally, it depended on the process template being used. The Scrum template had bug equated to Product Backlog items and that meant they were on the Product Backlog and couldn't be tasks on the Sprint Backlog. The Agile template had it the other way around as it was common in MSF Agile to report work directly against bugs.

In 2013 a feature was introduced that allows bug to configure where bugs show up:

enter image description here

The guidance for this feature can be found here:

  • https://docs.microsoft.com/en-us/azure/devops/organizations/settings/show-bugs-on-backlog?view=azure-devops

White robe scrum trainer answer

As a Scrum.org trainer I also have a more biased opinion about this. When you're working on a Product Backlog Item (or User Story depending on your naming convention) and you find an issue with it in your sprint, then it's not a Bug, you've just found a task you didn't know you hadn't finished yet as a team. Hence, in-sprint bugs are registered as a Task under the original Product Backlog Item (/User Story).

If you find a bug during the sprint that isn't related to the work at hand, you wouldn't immediately pick it up and fix it, instead you'd put it on the Product Backlog and work with the Product Owner to figure out when it makes sense to pull it into a sprint. Then you'd create a plan to fix it as part of Sprint planning (and add tasks to the Bug like you would for any other Product backlog Item).

In this setup, you'd never work directly against a Bug, most certainly wont make code changes against the bug.

You should of course figure out what works best for you and your team, but this is the sort of "scrum by the book" way of looking at bugs with regards to the Product Backlog and the Sprint Backlog.

enter image description here

Source: https://scrumcrazy.wordpress.com/2018/09/22/one-way-to-handle-production-support-and-bugs-in-scrum-bradley-bug-chart/

like image 71
jessehouwing Avatar answered Oct 28 '22 04:10

jessehouwing