Default are bugs visually in the product backlog. When a tester files a bugs from test manager (or any other client tool), it will be shown in the teams product backlog.
For example the bug found and saved with a test run in Microsoft Test Manager, will show up in the backlog with the state ‘New’.
When you look at the iteration path of this bug, you will see it is saved in the wrong area path. This will happen when you don’t set the area path of the test plan in the test plan properties. Even when you do set the test case iteration path correct.
Recommendation 1: set the test plan iteration properties before you do anything else.
Now the bug will also be seen in the sprint backlog, from where the team can commit to it, add tasks and handle it as a normal backlog item.
Now, not everybody is happy with the solution that every bug is visible in the backlog. many small bugs will blur the visual management capability of the backlog and task board, and maybe very big ones are to big to solve in the same sprint or need some more investigation and product owner collaboration.
The ‘too many too small bugs in the backlog’ situation can easy been solved; make the collaboration between developer en tester better and let them very quickly decide if it can be solved in the same hour, the same day or in the same sprint.
- For the same hour bug fix there is no need to create a work item type (wit) bug for it, just talk and solve the bug.
- For the same sprint bug fix you probably would create a task for so it appears on the task board and you don’t forget it.
So, find the bug – discus – solve or create task. It isn’t possible to create a task (for a bug) linked to a product backlog item directly from Microsoft Test Manager/ Test Runner. So this is going to be a manual activity, just open the task board and add the bug tasks.
so there are two solutions; or you add the bugs to the backlog (A) or you create tasks for it (B). In my point of view having them (the bugs) in the backlog is much better, mainly because of the rich bug information and the traceability (see image below – a bug with tasks, test case, pbi relations and data collector information).
When you definitely don’t want bugs in your backlog you can use another solution; create a separate bug backlog. It needs some more work but it works. (read this post from Mike Cohn)
The only way to create two backlogs is to work with areas. See below, I Added two areas.
My Team is responsible for the product backlog with just only Product Backlog Items.
This is how the backlog and sprint backlog look now. No more bugs, live is easy again
To get the bug backlog we have to create an additional team which does the bug triage. I created for this situation a bug triage team with as the one and only member ‘My Team’ with his members.
Make this team responsible for the ‘Bug Backlog’ area and we have a real bug backlog.
There is only one important decision left; how are we going to use the bug backlog, are we going to look at it at the end of the sprint or are we discussing it during the daily standup? And, what do we do with the bugs we are going to solve. It is easy to push them to the ‘real’ sprint backlog by changing the area path. We just prioritized and solved them directly from the bug backlog, and we didn’t used the sprint in the bug backlog.
My favorite solution is a blend of all three solutions:
- For very small one just create tasks.
- For a bit bigger bug but which we can solve in the same sprint, add them to the sprint backlog
- For very big ones which we don’t know add them to a separate bug backlog from where we can do a triage and push them back to the backlog for wider decision making or explanation by the product owner or just solve it and push it to the sprint backlog.