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.