How to Lead Multiple Scrum Teams: Scaling Scrum in Practice

A single Scrum Team can achieve a great deal. But some products are too large for one team, and organisations then face a new challenge: how can several teams work on the same product without losing the speed, focus and ownership that made Scrum work in the first place? This guide explains what the Scrum Guide says about multiple teams, the main scaling frameworks, practical ways to reduce dependencies and coordinate, and what leaders can do to help.

Key takeaways

• When several Scrum Teams work on one product, the Scrum Guide says they share one Product Goal, one Product Backlog and one Product Owner.
• They must also share one Definition of Done and produce an integrated Increment.
• Scaling frameworks such as Nexus, LeSS, SAFe and Scrum@Scale offer different ways to coordinate teams.
• Reducing dependencies, for example by organising teams around features rather than components, is often more effective than adding coordination.
• Make one team work well before scaling to many.

What the Scrum Guide says about multiple teams

The Scrum Guide describes a Scrum Team as small enough to remain nimble, typically ten or fewer people. If a Scrum Team becomes too large, the guide says it should consider reorganising into multiple cohesive Scrum Teams, each focused on the same product. Those teams should share:

• The same Product Goal, so all teams work toward one objective
• The same Product Backlog, the single source of work for the product
• The same Product Owner, one person accountable for maximising the product's value

The Scrum Guide also says that if several Scrum Teams are working together on a product, they must mutually define and comply with the same Definition of Done. Their work must combine into a usable, integrated Increment. Beyond these rules, the Scrum Guide does not prescribe how teams should coordinate, which is where scaling frameworks come in. For the basics, see Scrum artifacts explained and our complete Product Owner guide.

Why scaling is hard

• Dependencies: one team's work waits for another's.
• Integration: separate pieces must fit together into one working product.
• Alignment: teams may pull in different directions without a shared goal.
• Communication: the number of possible connections grows rapidly as teams are added.
• Loss of ownership: teams can become order-takers for a central plan.

The main scaling frameworks

Several frameworks describe ways to scale agile work. Each has its own guides and training, and organisations should study them in their own sources. Here is a brief, neutral overview.

Nexus

Nexus was introduced by Ken Schwaber, one of the creators of Scrum, and Scrum.org in 2015. It is designed for roughly three to nine Scrum Teams working on one product. It adds a Nexus Integration Team, which is accountable for ensuring an integrated Increment is produced, and extends the Scrum events with Nexus-level versions, such as Nexus Sprint Planning, a Nexus Daily Scrum, a Nexus Sprint Review and a Nexus Sprint Retrospective. It stays very close to Scrum.

LeSS (Large-Scale Scrum)

LeSS was developed by Craig Larman and Bas Vodde. Its basic framework is for around two to eight teams, with LeSS Huge for larger products. LeSS emphasises one Product Owner and one Product Backlog for the whole product, feature teams that can deliver end to end, and removing organisational complexity rather than adding roles and processes.

SAFe (Scaled Agile Framework)

SAFe was created by Dean Leffingwell and first released in 2011. It is a comprehensive framework covering team, programme and portfolio levels. Teams are grouped into Agile Release Trains that plan together in regular Program Increment (PI) Planning events. SAFe is widely used in large enterprises and defines many roles and practices, which some find helpful and others find heavy.

Scrum@Scale

Scrum@Scale was developed by Jeff Sutherland, the other co-creator of Scrum. It scales through networks of teams: a Scrum of Scrums coordinates delivery across teams, and a MetaScrum aligns priorities across a group of Product Owners and stakeholders. It is designed to be applied progressively as organisations grow.

The "Spotify model"

In 2012, Henrik Kniberg and Anders Ivarsson published a description of how Spotify organised its engineering teams into squads, tribes, chapters and guilds. It became widely copied as the "Spotify model". It was a snapshot of one company's approach at one point in time, and people involved have since cautioned against copying it as a framework. Its lasting value is in the ideas behind it, such as autonomous teams aligned to a clear mission, rather than its structure.

Scaling frameworks at a glance

Framework	Created by	Typical scale	Character
Nexus	Ken Schwaber and Scrum.org	About 3 to 9 teams	Minimal extension of Scrum
LeSS	Craig Larman and Bas Vodde	About 2 to 8 teams (LeSS Huge beyond)	Simplify the organisation; feature teams
SAFe	Dean Leffingwell	Many teams, up to large enterprises	Comprehensive, many defined roles and events
Scrum@Scale	Jeff Sutherland	Grows with the organisation	Networks of teams, Scrum of Scrums and MetaScrum

No framework is right for every organisation. Many successful organisations use a few simple practices rather than a full framework.

Reducing dependencies

The most effective way to scale is often to need less coordination in the first place.

Feature teams vs component teams

• Component teams own one technical part, such as the database or the mobile app. Almost every customer feature needs several of them, creating constant dependencies.
• Feature teams are cross-functional and can deliver a complete customer feature end to end. They depend on each other far less.

Moving towards feature teams is one of the most common recommendations in scaling frameworks, especially LeSS. It usually requires people to learn new skills and share code ownership, which takes time and leadership support.

Other ways to reduce dependencies

• Organise teams around customer journeys or product areas
• Split Product Backlog items so each can be done by one team
• Invest in automated testing and continuous integration so teams can integrate safely and often
• Agree clear interfaces between parts of the system

Practical coordination practices

Whatever framework you use, or none, these practices help teams work together:

• Shared refinement: representatives from several teams refine upcoming items together, spotting dependencies early.
• Cross-team Sprint Planning: teams plan at the same time, or hold a short joint session before planning separately.
• Aligned Sprints: teams start and end Sprints on the same days so integration and review happen together.
• Integrated Increment: teams integrate continuously so there is always a working whole, not separate pieces.
• Joint Sprint Review: stakeholders see the whole product, not a series of separate demos.
• Overall Retrospective: representatives from each team look at how the teams work together.
• Scrum of Scrums: a short, regular meeting of team representatives to resolve cross-team impediments.
• Communities of practice: people with similar skills across teams share knowledge and standards.

For how each Scrum event works, see the five Scrum events explained.

One Product Backlog, one Product Owner

With several teams, the Product Owner's job becomes larger. The Scrum Guide keeps the Product Owner as one person, although they may delegate backlog work to others and remain accountable. Many organisations support the Product Owner with people from each team who help refine items. The Product Backlog needs to show clearly which items depend on each other, and ordering must consider the whole product, not each team separately. See how to manage a Product Backlog.

The leader's role in multi-team settings

• Keep the goal clear: one Product Goal that every team understands.
• Design teams well: stable, cross-functional, feature-oriented teams with minimal dependencies.
• Remove cross-team impediments: the problems that no single team can solve.
• Protect autonomy: coordinate outcomes, not tasks.
• Invest in technical foundations: automation and integration make scaling far easier.
• Resist adding layers: every new role or meeting should earn its place.

For the wider leadership picture, see our complete agile leadership guide.

Measuring multi-team performance

• Integrated, working Increments: does the whole product work at the end of each Sprint?
• Cycle time for features: how long does a customer feature take from start to delivery across teams?
• Dependency wait time: how often and how long do teams wait for each other?
• Customer outcomes: is the product delivering more value?

Avoid comparing teams on velocity; teams work on different items and estimate differently. See Kanban metrics explained for flow measures that work across teams.

A worked example: from one team to three

As an illustration, imagine a product with one Scrum Team of nine people. Demand grows and the organisation hires six more people. Rather than creating one team of fifteen, it forms three teams of five:

• Team structure: each team is cross-functional and organised around a customer journey, such as sign-up, payments and account management, so most items can be done by one team.
• One backlog, one Product Owner: the existing Product Owner keeps a single ordered Product Backlog, with a representative from each team helping refine items.
• Aligned Sprints: all three teams start and end their two-week Sprints on the same days.
• Shared Definition of Done: the teams agree one Definition of Done, including automated tests that run on every change.
• Joint events: a short joint session before Sprint Planning to spot dependencies, a joint Sprint Review for stakeholders and an overall Retrospective once a month.

After a few Sprints, the teams notice that payments work often waits for the account team. They move one developer with account knowledge into the payments team and split items differently, reducing the dependency. The structure evolves based on what they learn.

Signs you are ready to scale

• At least one team reliably delivers Increments that meet the Definition of Done.
• The Product Owner can keep a clear, ordered Product Backlog.
• There is enough automated testing to integrate work from several teams safely.
• Demand genuinely exceeds what one team can deliver.
• Leaders are prepared to design teams around features rather than components.

Flow across several teams

Flow practices help at scale too. Visualising work across teams on a shared board, limiting how many large features are in progress at once, and measuring how long features take from start to delivery all make cross-team problems visible. Limiting work in progress at the level of features is often one of the most effective ways to reduce the waiting between teams. See WIP limits explained.

Common mistakes

• Scaling before one team works well. Scaling a dysfunctional process multiplies its problems.
• Several Product Owners for one product. Competing priorities pull teams apart.
• Separate backlogs per team. The whole product loses a single order of value.
• Component teams everywhere. Constant dependencies slow everything down.
• Too many coordination meetings. If teams spend more time coordinating than building, reduce dependencies instead.
• Integrating only at the end. Late integration hides problems until they are expensive.
• Copying another company's model. Learn from others, but design for your own context.

Build your skills

Leading several teams is a major step up. Scrum Leader Plus covers coaching multiple teams, cross-team dependencies and organisational change. The exam is taken online on ExamVault by CertExpert with three attempts included, and the certificate and digital badge are valid for two years. See the certification page for current learning paths and prices. For an advanced Scrum Master path, see our CSP-SM guide.