Let's say my company has a project, and there's enough work that 10-12 developers are needed, minimum. We want to break up the Scrum team into two separate ones, but this is our first time doing that at this company.

What kinds of things should we consider before trying to do this? Are there any particularly good online resources or books to consult? Mostly everything I've found just suggests Scrum of Scrums and stops there - SoS is clearly required, but what else?

Most information on "scaling scrum" or doing "large scale scrum" are too big for us - we just want two to three small teams, maybe with a scrum master each, and we'll have to have just the one product owner for the whole project.

3 Answers 3


With just two scrum teams, a true scrum-of-scrums may not even be needed. If your teams are co-located, they could do their daily scrum back to back and have a team member from the other team present to relay any important information. This becomes impractical after say 3 or 4 teams, which is when a SoS is a better solution (though scrum.org has started to recommend a concept called Nexus Daily Scrum, which is before, not after the normal daily scrums).

The biggest problem when going to two teams is that both teams still should produce only 1 integrated increment to the product they're building. This requires coordination between the teams and possibly collective effort to ensure that you end up with a releasable increment. Your development practices will also need to be adjusted to support this. With multiple teams it becomes even more important to focus on finishing what you started before picking up new work (a concept called Work in Process Limits from the Lean world applies in these cases).

Your product owner job will likely be a full-time role. One product owner for both teams is the recommendation from almost all agile practitioners. With two teams you will not yet need to delegate the role of the product owner as long as this person is available most of the time.

Another issue that will most certainly pop-up is cross team dependencies. You'll want to minimize these by the way work is ordered. If teams are heavily dependent on eachother it's far harder to operate as separate teams and you'll need a lot more cross team communication than when both teams can work mostly independent.

A common pattern is to have a single Sprint Review for the product if the teams are working on one product.

Another common pattern is to split the Sprint Retrospective into two parts, one focusing on how the teams work together, the other focusing on how each team works as a group. For the second part the teams each go into their own area or a private meeting room to ensure the trust level is maximized when talking about possible conflicts, ways to optimize and roadblocks.

On Refinement it helps to have a mix of both teams present. If you have been doing refinement with the whole team present, this may become too hard (too many people) and too expensive to invite everyone. It is important that outcomes and important choices are fed back into the teams so that everyone understands the reasoning behind the choices made. By having both teams participate together you ensure that any team potentially can pick up the work.

There is some good literature available on this topic and there is a lot of guidance to be found in the larger scaling frameworks. Just remember, since you're scaling small, a lot of these large practices will be overkill. After the team has split itself up, see where you can improve and look at the resources available to you in these larger scaling models to look for common patterns. Try them, see if they work for you. If they don't go back to the basics.

Scaling frameworks to investigate for common patterns:

  • Scrum.org Nexus
  • Less
  • SAFe - I'd stay away from this for now, it's focused on so much larger organisations that you're likely to pickup bad habits, instead of good practices.

The authors of Less have written two books on agile scaling, they provide loads of experiments they've seen working in certain situations.


Based on previous experiences, some things to consider:

  • How will the backlog correlate to teams? Does it make more sense to have them in one backlog (and perhaps flag items as favorable for one team), or two backlogs? Does it make sense to have them "own" feature sets or do you want to improve knowledge sharing and robustness by mixing it up, or even requiring crossovers? How can you maximize visibility of the backlog to help mitigate the impact of Scrum of Scrums?
  • Will sprints coincide or be offset, and will they be the same length? (and it may vary depending on needs to create/review/plan). There are pros and cons to each approach, and the impact can vary for teams vs. stakeholders vs. PO, etc.
  • How should they sit in order to benefit from team focus as well as cross-communication or "conversation spill", or maybe roles/frequent cross-team dependencies?
  • Should you alter standup formats or composition? Does it make sense to have them all together, or separate? If the latter, should certain people attend the others, again to help mitigate the impact of Scrum of Scrums?
  • Do both teams even need to do Scrum? Does it make more sense for one team to do kanban or another approach? I've had a few situations where one team was feature-focused and one team was content-focused so two approaches made sense.
  • Take care of your Product/Sprint Backlogs: Since you have only one project work split between two teams, ensure your product backlog is refined properly and split in to two sprint backlogs with no dependency(or minimum dependency). (If there is any dependencies between these two sprint backlogs ensure that it is commented in relevant stories. Just remind the teams during sprint planning about the dependencies. Ensure that developers who ever working on these dependent stories of two sprint backlogs should communicate with each other. They can attend both the daily standups if needed.)

  • Start two sprint planning meetings.

  • Have two daily scrum calls.

  • Have two sprint review and retrospective calls.

No need to go for LeSS or SAFe.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.