![]() ![]() Trackable on the backlog, by users, and team members – but more importantly: ready for priorization. Therefore, they should be product backlog items in my opinion. A defect is only worthy of tracking as a bug as soon as it is reported by users and no sooner. As long as the story is not complete, anything that is not working properly yet, is just work to be done. My personal belief is that it makes no sense to track bugs as tasks, under a user story. Now, which one do you choose? I think it depends on how you work and what you use the ‘bug’ work item for. On the right is the sprint view, here the bugs no longer apear on the left, but instead they can be added to user stories, just as tasks. When tracking bugs as tasks, they do not appear on the product backlog along with user stories, as you can see below, on the left. Here both appear on the left and you can add tasks to bot the stories and the bugs, to work towards completing the work. On the right, you see the same stories and tasks in the sprint backlog. They are nestable below features and you can prioritize them against other work within the feature. When you are tracking bugs as user stories, they appear on the product backlog, along with the user stories, you see this below, on the left. In the pop-up that opens, select ‘Working with bugs,’ to find the option you are looking for.īut which option to choose? Let’s explore the first two alternatives in a bit more detail to help you decide which to use. Next, click the cogwheel icon at the top right. To get here, first, navigate to your sprint board or product backlog. ![]() Here you can see how to choose between the three options: If you don’t want to use the bug work item type, then just don’t. It is beyond me why you would want to do this. Not tracking bugs, effectively disabling the ‘bug’ work item type.Instead, within every user story on the backlog, you can add one or more bugs You cannot track bugs on the product backlog directly, cannot group them under a feature, and cannot add them to a sprint directly. This allows you to create bugs as a child to a user story. Once in the sprint backlog, you can add one or more tasks below the bug, tracking progress towards resolving it This allows you to create bugs on the backlog, where they behave just like user stories: you can group them under a feature, order them for priority and move them to the sprint backlog when you are ready to begin work on them. Once you have selected a work item process that allows for tracking bugs, you can decide how to track bugs. It also has the benefit over the Basic process of having two levels of grouping for user stories: both epics and features.įor the remainder of my examples, I have selected the Agile process. My personal favorite is the Agile process, as I prefer the term ‘User Story’ over Product Backlog Item or Requirement. To track bugs on your backlog, you will have to choose the Agile, CMMI, or Scrum process. Selecting a different work item process is available under the Advanced options when creating a project:Įach work item process has different types of work items available, which are all listed here. The work item process is selected when you create the Project, and cannot be changed afterward. But before we get to that, let’s explore choosing a work item process. Secondly, once you have chosen a work item process that supports tracking bugs, you have to configure how you want to track bugs: as a backlog item, or as a task. Within Azure DevOps, the work item types (epic, feature, user stories, tasks, etc) that are available, is controlled by the work item process you choose for your project. And of course, this is possible with the correct configuration. ![]() When you are using Azure DevOps for tracking work items like features, user stories, and tasks, you probably want to track bugs in that same system. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |