Teams in Visual Studio 11 CTP, The Bug Backlog.
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.
Teams in Visual Studio 11, feature teams and backlogs.
Before continue reading, read the basics - Teams in Visual Studio 11, the basics -
Sometimes a project is bigger than one team can handle (with the recommended team size, see the scrum guide). A solution for this big project problem is the creation of multiple teams and organize scrum of scrums meetings. With the scrum of scrums meetings we hope we will solve the possible integration and reuse problems.
According to Mike Cohn, author of Agile Estimating and Planning, The Scrum of Scrums (SoS) meeting "is an important technique in scaling Scrum to large project teams. These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration."
Scrum of Scrums - Issues and Value
From a backlog perspective we also have to make a decision, are we going to use one backlog for multiple teams or one backlog per team.
One backlog for multiple teams
In TFS vNext this can be done by assigning the same area to the different teams. in this way they will get the same backlog, and can commit to backlog items for a sprint.
This solution will get more challenging during the sprint planning meeting. The teams also have the same sprint backlog.
I do think teams will create a mess out of this, asking questions like “did we committed to this backlog item or did the other team do it?” and “how much do we burn each sprint?”.
Both teams also share the same task board in TFs vNext when configuring them for the same area, which doesn’t make everything more clear.
I would recommend don’t use the one backlog for multiple teams configuration. So, make teams responsible for their own area in TFS vNext (actually not only in TFS but always).
One backlog per team
One Team, One Backlog is easy configure in TFS vNext, just use the area’s. So, first we must add the necessary area’s for our teams.
Just add new child's to the project (don’t make it too complex). One important thing is that you define the area’s as functional slices, not horizontal slice. For example data layer, business layer or cross cutting concerns aren’t allowed (teams make functionality end users can use!).
Now we have our areas we can set some restrictions (not really necessary when teams trust each other, but it will help making mistakes).
Add the team
Default a team which is added to an area inherits the rights from contributors.
and in the contributors TFS group are all the teams.
So we need to set in the area that other teams aren’t allowed to edit work items. Adding those teams and set their permissions to deny will do the trick. Now the other teams can’t accidentally play with each others backlogs anymore.
(I hope Microsoft will make these messages more friendly.)
All teams follow the projects sprint cycle (see also previous post), but with a different area. When a team is active in a sprint can be configured in the team administration section. It’s not preferable to put a team to sleep for one or two sprints but you can do it.
There are many more solution scenario’s how to handle big project, the presentation download on this page “Scaling Scrum” gives a nice overview of the possible solutions for big agile projects. I do think a backlog per team would be sufficient in 80% of the big project scenario’s.