Change the Scrum Guide™
What is Scrum?
Definition of Done
Scrum and Agile Webcasts
Professional Scrum Foundations™
PSF Subject Areas
Professional Scrum Master™
PSM Subject Areas
Professional Scrum Product Owner™
PSPO Subject Areas
Professional Scrum Developer™
PSD Subject Areas
Scrum Open Assessment
Developer Open Assessment
Professional Scrum Master™ Assessments
PSM I Assessment
PSM II Assessment
Professional Scrum Product Owner™ Assessments
PSPO I Assessment
PSPO II Assessment
Professional Scrum Developer™ Assessments
PSD I Assessment
Work With Us
By posting to our forums you are agreeing to the
difficulty managing multiple scrum teams
Last Post 06 Sep 2013 09:21 AM by Ian Mitchell. 5 Replies.
Most Recent First
You are not authorized to post a reply.
27 Apr 2013 10:07 PM
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?
27 Apr 2013 11:00 PM
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).
16 May 2013 05:11 PM
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.
17 May 2013 04:59 AM
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.
06 Sep 2013 07:41 AM
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?
06 Sep 2013 09:21 AM
> 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.
You are not authorized to post a reply.