difficulty managing multiple scrum teams
do you have experience or insight into managing multiple scrum teams. I know we should have a single product backlog we work from. not sure if I can have multiple teams working their own separate sprints with separate timelines/timeboxes or everyone should have same product backlog and their respective sprints should start / end at the same time?
anyone experienced with multiple teams?
Sometimes we're working on a very large initiative. Allowing 1 Scrum Team to grow is natural.
However, we also don't want to get too many people on the same time where the environment actually hampers or slows down things.
The Scrum Guide gives guidance on recommended team size.
Multiple teams can then work of the same product backlog.
Whether they should coordinate to have the events at the same time, or differently is situational and depends on a few variables. They don't have to start or end at the same time as other teams.
Instead, what I would think of is how the DoD is understood so that the Product Owner can accept the increment at the end of the Sprint(s).
About your question, may have the same or different lengths. The duration of the sprint and alignment with other groups depend on how you divide the product (components, layers), the time that each team needs to give an increment of the product, the necessity and difficulty of synchronization, the establisheddefinition of done is , etc.
Anyway, for this question and others that you may have about interaction and organization between SCRUM teams, I suggest the book "Scrum and the Enterprise" by Ken Schwaber.
Sprints don't *have* to be synchronized or of the same length, but it will probably be more efficient if they are.
This is because each team must deliver a potentially releasable increment at the end of each Sprint. If those Sprints don't synchronize then the delivery of value will be delayed. At least one of the teams will have finished their Sprint, but the value of their work will decay until the other teams finish their Sprints, and are themselves ready to contribute to a release.
Of course, the decay in value could be marginal. Having incompatible Definitions of Done is likely to be a far bigger problem, as it can easily lead to the cascading of technical debt. I'd focus my efforts on getting rock-solid and compatible DoD's in use across all teams first.
If you have multiple teams working on one product backlog:
1. Which one of the product owners have the final say of the contents of this backlog?
2. Since scrum is stating that the teams should have the same start dates on there sprints, how do we prevent more than one team to pick the same Product backlog item to work with?
> If you have multiple teams working on one product backlog:
> 1. Which one of the product owners have the final say of the contents of this backlog?
There should be one product owner for one product backlog. That PO may delegate certain operational matters to proxy PO's. Those proxies may then represent him or her in front of the development teams. The PO retains ownership of the product backlog contents.
> 2. Since scrum is stating that the teams should have the same start dates on there sprints, how
> do we prevent more than one team to pick the same Product backlog item to work with?
If product ownership was represented by proxies, they would have to co-ordinate with (and defer to) the product owner on such matters.
Note: proxying is just one possible approach (although it's a common one). Scrum doesn't have anything to say about proxies. They can be dangerous in so far as they can lead to weak product ownership.