How many Sprint Backlogs do you have? We have one for the entire project, and I must admit that there is no good reason for that. As it appears, the general recommendation is to have one per team.
Benefits:
- each team feels more committed to the document and to the burndown chart
- delays specific to a team would not get hidden by progress made by other teams
- designing the Sprint Backlog would take less time
- one Track Master (if applicable) per team can be in charge of the Backlog, as opposed to one person in charge of the entire project
Cons:
- more documents to manage, but responsibility is clear and one person is still in charge of no more than one
- document styles may diverge (not a big deal)
- when starting from the Product Backlog, it is more difficult to figure out where to look to see progress on a particular feature; this should not be much of a problem, considering that stories are usually clearly assigned to particular teams; it might help to add a column in the Product Backlog that gives the name of a team in charge of each story
- no synthetic view for PO & management; this might be the real difficulty. For example, in our case, management and customer have been sold on the idea of applying Scrum because it would make it easier to see progress during in the course of an iteration. This should be mitigated by the facts that
- a Sprint Backlog is made for the Pigs (the Team), not for the Chickens (management) or even the Product Owner; it is the team’s own tool, not anyone else’s
- it is probably not too hard to combine automatically the teams’ Sprint Backlogs into an overview document
All in all, it seems that the benefits are much higher than the disadvantages. So, what are you (& we) are waiting for?
Check out the complete discussion on that very subject in the Scrum Development mailing list.
