Scrum of Scrums: How to Coordinate Multiple Scrum Teams

By Tara Minh · Updated Oct 10, 2026

A Scrum of Scrums is a short, recurring meeting where one ambassador from each Scrum team shares progress, flags impediments, and sorts out dependencies with the other teams. It scales the daily stand-up from one team to several, without adding a management layer or a new planning ceremony.

Key Facts

• Agile Alliance defines it as a technique for scaling Scrum to groups of more than a dozen people, divided into Agile teams of 5 to 10, with each team naming an "ambassador" to a meeting of ambassadors.
• The Scrum@Scale Guide credits IDX with creating the Scrum of Scrums and says it first allowed Scrum to scale to hundreds of teams.
• Per the same guide, the optimal number of teams in one Scrum of Scrums is 4 or 5, and the scaled Daily Scrum is time-boxed to 15 minutes or less.
• Atlassian dates the first use to 1996, by Jeff Sutherland and Ken Schwaber, and says Sutherland first mentioned it publicly in a 2001 article, "Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies."
• The Scrum Guide itself doesn't mention Scrum of Scrums. It's a technique layered on top of Scrum, not part of the core framework.

Where Scrum of Scrums came from

Sources differ a little on the exact origin story, and it's fair to say so. Atlassian's history of the technique says Sutherland and Schwaber first used it in 1996 to coordinate several business units, each with multiple product lines. The Scrum@Scale Guide credits IDX with creating it. And Agile Alliance notes that Sutherland first described it in 2001, summarizing experience at IDX.

What the sources agree on is the problem it solved. One Scrum team can run itself in a 15-minute daily stand-up. Put four or five teams on the same product and nobody sees the whole picture. Team A waits on an API from Team B. Team C changes a shared component and breaks Team A's build. Nobody learns about it until the Sprint Review.

Scrum of Scrums is the smallest fix for that: a meeting small enough to stay short, and frequent enough to catch problems while they're cheap.

How Scrum of Scrums works

The mechanics are simple, which is why the technique has lasted.

1. Each team runs its own Daily Scrum as usual.
2. Each team sends one ambassador to a second, shorter meeting.
3. The ambassadors cover what's done, what's next, and what's blocked, with a focus on how their work touches other teams.
4. Anything that needs a deeper conversation moves to a breakout with just the people involved.

Agile Alliance describes the ambassadors as technical contributors, Scrum Masters, or team managers, depending on context. It adds that impediments get resolved with a focus on coordination, such as agreeing on interfaces or negotiating who owns what. The meeting also keeps its own backlog, where each item exists to improve coordination between teams.

Who attends

Pick ambassadors who can speak for their team and commit it to something. Atlassian's guidance is that representatives need enough context to speak for the team and the authority to make decisions or escalate. Rotating the role spreads understanding and shared ownership, and it keeps the meeting from becoming one person's job.

In larger programs, program managers, project managers, or engineering managers who oversee several teams may join too. The risk is that a room full of managers turns the meeting into a status report. Keep the focus on dependencies and blockers.

How often and how long

Scrum@Scale time-boxes the scaled Daily Scrum to 15 minutes or less. Atlassian suggests holding it right after the last team Daily Scrum, so ambassadors arrive with fresh information. Daily is the default. Some groups with loosely coupled teams meet two or three times a week instead, which works as long as impediments don't sit unseen for days.

The questions to ask

The Agile Alliance glossary names three categories of report: what's been completed, what comes next, and what's blocking. The Scrum@Scale Guide adds a cross-team question for the scaled Daily Scrum: whether any new dependencies between teams have been discovered, or a way to resolve an existing one. Put together, a working agenda uses four questions per ambassador:

The fourth question is the one that earns the meeting its place. The first three could be an email. The fourth makes people think about the neighbors.

The Scrum of Scrums Master

Scrum@Scale gives the meeting a facilitator: the Scrum of Scrums Master. Per the guide, this person ensures the scaled events take place and are productive and positive, and helps remove cross-team dependencies. The Atlassian overview adds that the role should keep the progress and impediment backlogs visible to other teams, and push for prioritization or removal of impediments.

It's a facilitation job, not a command job. The Scrum of Scrums Master doesn't assign work to teams. If you've read about how a team-level Scrum Master differs from a Product Owner, the same split applies here: one person serves the process, another owns what gets built and in what order.

Scaling further: a Scrum of Scrums of Scrums

When one group of teams isn't enough, the pattern repeats. The Scrum@Scale Guide says a Scrum of Scrums of Scrums (SoSoS) can be created out of multiple Scrums of Scrums, with each level getting scaled versions of the roles, artifacts, and events. The guide's advice on group size is 4 or 5 teams per Scrum of Scrums, so the arithmetic stays manageable: four groups of five teams is twenty teams, covered by two layers of ambassadors.

Scrum@Scale also gives impediments somewhere to go. Its Executive Action Team fulfills the Scrum Master accountabilities for the whole organization and handles impediments the teams can't resolve. The guide says its members must be empowered, politically and financially, to remove them. That's the part many Scrum of Scrums implementations skip. An ambassador meeting that surfaces blockers nobody has the authority to fix is just a faster way to watch problems stay open.

Scrum of Scrums vs other scaling approaches

Scrum of Scrums is a technique, not a full framework. That's both its strength (you can start tomorrow) and its limit (it doesn't tell you how to plan, prioritize, or structure the organization). Here's how it sits next to the usual alternatives.

A few notes on the table.

Nexus is the Scrum.org answer. The Nexus Guide describes it as minimally extending Scrum so that multiple teams work from a single Product Backlog to build an Integrated Increment. Where Scrum of Scrums only coordinates, Nexus adds structure aimed squarely at integration. See the Nexus framework article for the detail.

SAFe has its own version of the idea. The ART Sync brings together the PO Sync and the Coach Sync, typically as a single event, and serves as an escalation point for operational impediments that teams can't resolve locally. Attendees include Business Owners, product roles, the Release Train Engineer, Scrum Masters or Team Coaches, and System Architects. That's a Scrum of Scrums with more roles and a planning cadence attached. For the full picture, see SAFe.

LeSS avoids needing an ambassador meeting for most coordination, because all teams share one backlog and one Sprint. The trade is that it asks for real organizational change. Read the LeSS framework article before deciding.

The Spotify model isn't a rulebook. It's a description of how one company organized itself, and it leans on chapters and guilds for cross-squad sharing. Squads still need a way to resolve dependencies day to day, and many fall back on a version of Scrum of Scrums. More in the Spotify model article.

If your teams aren't yet running Scrum well on their own, fix that first. Atlassian puts it bluntly: if you struggle with Scrum at the individual team level, you can't scale those practices across a team of teams. The Scrum basics are the prerequisite.

How to run a Scrum of Scrums: step by step

1. Decide whether you need one. If your teams share a product, a codebase, or a release date, and dependencies keep surprising people, you do. If teams work on unrelated products, you don't.
2. Cap the group. Aim for 4 or 5 teams per meeting, per the Scrum@Scale guidance. Beyond that, split into two groups and add a layer above.
3. Choose ambassadors. Pick people with context and authority to commit. Agree on whether the role rotates.
4. Pick a slot. Hold it right after the last team Daily Scrum, 15 minutes, same time every day.
5. Name a facilitator. Someone owns the agenda, the timebox, and the impediment board.
6. Use a fixed agenda. The four questions above, in the same order, every time. Park anything longer than a minute.
7. Keep one impediment board. Every blocker gets an owner, a date, and an escalation path.
8. Define the escalation route. Decide in advance who can clear a blocker the teams can't. Without this step the meeting just lists problems.
9. Review the meeting itself. Add Scrum of Scrums to the cross-team retrospective: is it too long, too status-heavy, missing the right people?

Agenda and impediment board template

Copy this into your wiki, shared doc, or board.

Meeting agenda (15 minutes)

Impediment board

Keep it to open items. Close and archive anything resolved, so the board stays short enough to scan in one minute. If the same kind of blocker keeps coming back, log it in your RAID log as a risk or dependency, where it gets a proper owner and review cycle.

Examples across functions

Scrum of Scrums is most often associated with software, but any group of teams with interdependent work can use the pattern.

Product engineering. Four teams build a mobile app, an API, a web client, and a data pipeline. The mobile ambassador reports that a release is blocked on an API field. The API ambassador confirms the field ships Thursday. Nothing escalates, and nobody waited until the Sprint Review to find out.

Marketing. A campaign involves content, paid media, web, and lifecycle email teams. The web ambassador says the landing page template won't be ready until Wednesday. The paid media ambassador, about to launch ads on Tuesday, moves the start date. That's question four doing its job.

HR and people operations. Recruiting, onboarding, payroll, and benefits teams are rolling out a new hire process together. Onboarding learns that recruiting will change the offer-letter format mid-Sprint, which affects its checklist. They agree on the new format in the meeting and take the details offline.

Operations. Warehouse, procurement, logistics, and customer support teams are preparing for a seasonal peak. Procurement flags a supplier delay. Logistics adjusts delivery slots, and support updates its messaging before customers ask.

Finance. Accounting, FP&A, and compliance teams close the quarter together. Compliance needs an audit report from accounting by Friday, and accounting needs a forecast lock from FP&A first. The dependency chain is visible in two minutes instead of a week of email.

Do's and don'ts

When Scrum of Scrums isn't enough

The technique stops working when the real problem is structural. If every Sprint ends with teams fighting over a shared component, an ambassador meeting won't fix the architecture. If teams disagree on priorities, they need a shared backlog and a single decision-maker, which is what Nexus and LeSS provide. If dozens of teams need synchronized planning across quarters, a framework like SAFe offers cadences that Scrum of Scrums doesn't.

A good test: if the same impediment appears on the board three Sprints in a row, the issue isn't coordination. It's design, ownership, or priority, and it needs a decision from someone above the teams.

Scrum of Scrums works because it's small. It adds one short meeting, one impediment board, and one person to facilitate. Start there, watch which problems keep returning, and let those tell you whether you need a heavier framework or a structural fix.