difficulty managing multiple scrum teams

Hi Jbeek,

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).

Hello jbeek,

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.

Regards.

Hi jbeek

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.

Hi.
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.

Since scrum is stating that the teams should have the same start dates on there sprints

I was wondering where you've found this? I can't find it in the Scrum Guide or other material.

I am going to go a completely different way on this one.  

Are you sure that the two teams are working on the same Product? Is it possible that the Product could actually be better served by treating it as two products?  Yeah, I know that is unusual but it is always one thing I ask before we decide to put two teams on a single product backlog.  Just because it is one code base does not mean that it can't be treated as two products especially if analysed well. It makes things a lot easier and all of the coordination then occurs between the two POs.  I have had a couple of occasions where this approach turned out to be the best.  But it is not possible all the time. 

If you do need two teams working the same Product Backlog, I suggest that the PBIs be created with that in mind.  Make sure that they are truly independent from any others so that dependencies are eliminated as often as possible. If there have to be dependencies, then the same team should work all of those stories even it if has to span multiple sprints.

I'm also going to assume that you are a single Scrum Master for two teams.  If so, I suggest staggering the sprints, at least by a couple of days.  It will be near impossible for you to do two sets of Events on the same day.  I usually will stagger them where I have one set of events each week. That gives me time to help get the team rolling on their sprint and facilitate refinement sessions in preparation for the sprint starts.  At a minimum try to stagger them so that one team starts Monday or Tuesday and the other on Thursday or Friday.  Even having them back-to-back days can be a real challenge.