Scrum of Scrums: Definition, Agenda, Roles, and Enterprise Scaling Guide (2026)

Key Highlights

• Scrum of Scrums (SoS) was introduced by Jeff Sutherland and Ken Schwaber in 1996 at Lawrence Livermore National Laboratory to coordinate 8 business units with multiple product lines in a single development cycle.
• Over 75% of agile teams that scale across multiple departments report difficulty coordinating cross-team dependencies. Scrum of Scrums is the most widely adopted solution (Knowledge Academy, 2026).
• Scrum of Scrums is NOT part of the official Scrum framework. The Scrum Guide does not mention it. It is a scaling technique developed alongside Scrum.
• In SAFe, the ART Sync event serves a similar coordination function to Scrum of Scrums but is specifically designed for multi-ART environments.
• For organizations with 5+ Scrum teams working on connected programs, a nested structure called Scrum of Scrums of Scrums (SoSoS) creates a hierarchical coordination layer above SoS.

Introduction

Scrum of Scrums (SoS) is a scaled agile coordination technique where representatives from multiple Scrum teams meet regularly to synchronize progress, surface cross-team dependencies, and resolve inter-team impediments. It scales the Daily Scrum concept up to the program level without making the Daily Scrum itself unwieldy by adding too many participants.

Scrum of Scrums was introduced in 1996 by Jeff Sutherland and Ken Schwaber, the co-creators of Scrum, while they were working to coordinate eight business units with multiple product lines at Lawrence Livermore National Laboratory. They found that having separate Scrum teams for each business unit created coordination gaps. Gathering one representative from each team into a higher-level synchronization meeting solved the problem while preserving each team’s autonomy.

Scrum of Scrums is not part of the official Scrum Guide. This is important: organizations that expect Scrum of Scrums to be prescribed by the Scrum framework sometimes struggle to justify it internally. It is a complementary scaling technique, not a Scrum event. For organizations using SAFe, the ART Sync event provides a more structured, formally governed equivalent at the program level.

What Is Scrum of Scrums?

Scrum of Scrums is a technique for coordinating multiple Scrum teams working on a shared product or program. When 2 or more Scrum teams work on connected deliverables, dependencies, shared services, and integration risks require coordination above the individual team level.

The core mechanics:

• Each Scrum team selects one representative (called the “ambassador”) to attend the Scrum of Scrums meeting
• Ambassadors meet at a regular cadence to share progress, surface cross-team blockers, and coordinate dependencies
• The Scrum of Scrums meeting follows a structured 4-question agenda derived from the Daily Scrum
• Each Scrum team continues to run its own internal Daily Scrum independently

Most organizations do not introduce Scrum of Scrums because they are scaling successfully. They introduce it because coordination has already started to break down.

A common misconception is that adding more Scrum teams automatically increases delivery capacity. In practice, every additional team introduces new communication paths, dependencies, integration points, and decision-making complexity. What worked with one team often becomes difficult with three teams and chaotic with six.

Scrum of Scrums exists to solve three scaling problems:

• Dependency Visibility

Team A cannot complete its work because Team B owns a shared API. Without a coordination mechanism, that dependency often surfaces too late.

• Integration Risk

Individual teams may successfully complete their sprint goals while the integrated product remains unstable or incomplete.

• Decision Synchronization

Teams frequently make local decisions that unintentionally create downstream impact for other teams. Scrum of Scrums creates a forum where those impacts become visible before they become expensive.

The purpose of Scrum of Scrums is not reporting status. Its purpose is reducing coordination cost while preserving team autonomy.

When you need Scrum of Scrums:

• You have 2 or more Scrum teams working on connected features or a shared product
• Cross-team dependencies are creating sprint blockers for individual teams
• Integration issues between teams are surfacing late in the sprint
• Communication gaps are causing duplicated work or conflicting decisions

Many organizations underestimate how much delivery time is lost to unmanaged dependencies.

A team blocked for two days waiting on another team’s API may appear productive because individual stories remain in progress. At the program level, however, delivery throughput slows significantly.

Research from the book Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim shows that high-performing technology organizations reduce handoffs and dependency delays wherever possible because coordination overhead directly impacts delivery speed.

A well-run Scrum of Scrums cannot eliminate dependencies, but it can dramatically reduce the time teams spend discovering and resolving them.

When Scrum of Scrums is NOT the right solution:

• You have 1 Scrum team. Use the Daily Scrum instead.
• You have 10+ Scrum teams. Consider SAFe ART Sync or a SoSoS structure instead.
• Your teams work on completely independent products with no integration points. No coordination meeting needed.

Scrum of Scrums Roles

The Ambassador

The ambassador is the representative each Scrum team sends to the Scrum of Scrums meeting. Choosing the right ambassador is one of the most impactful SoS design decisions.

One of the most common reasons Scrum of Scrums becomes ineffective is ambassador selection based on hierarchy rather than relevance.

Organizations frequently default to sending:

• The Scrum Master
• The team manager
• The most senior person

Instead of sending:

• The person closest to the dependency
• The person who owns the affected work
• The person capable of making or escalating decisions quickly

A useful rule is simple:

The ambassador should be the person most likely to answer dependency questions from another team without saying, “I’ll need to check and get back to you.”

The role may rotate sprint by sprint depending on where the highest coordination risk exists.

Who makes the best ambassador:

• A team member with deep current knowledge of the team’s sprint work and blockers
• Someone with decision-making authority or direct access to decision-makers
• Not necessarily the Scrum Master (though Scrum Masters often attend by default)
• The right ambassador changes based on the sprint’s work. A senior developer with ownership of the current sprint’s highest-dependency stories is often more valuable than the Scrum Master.

The ambassador’s responsibilities:

• Attend the SoS meeting prepared with the team’s status on the 4 questions
• Represent the team’s blockers, risks, and dependencies accurately
• Return to the team after the SoS and share decisions and coordination outcomes
• Escalate issues that cannot be resolved at the SoS level

The Scrum of Scrums Master

For larger SoS configurations (4+ teams), some organizations designate a Scrum of Scrums Master  a role analogous to the Scrum Master but at the program coordination level. The SoS Master:

• Facilitates the Scrum of Scrums meeting
• Tracks cross-team impediments and ensures resolution
• Escalates program-level blockers to leadership or the Product Manager
• Connects the SoS coordination outcomes to individual team sprint planning

In SAFe, the Release Train Engineer (RTE) fulfills this role for the Agile Release Train. NextAgile’s SAFe consulting services include RTE coaching and PI Planning facilitation as core delivery components.

The Scrum of Scrums Meeting Agenda: The 4 Questions

The Scrum of Scrums meeting follows a 4-question agenda adapted from the Daily Scrum’s 3-question format. The fourth question is the critical addition that distinguishes SoS from a simple multi-team standup.

The 4 SoS questions each ambassador answers:

1. What has my team accomplished since we last met? Focus on completed work that other teams depend on or that represents integration risk.
2. What will my team accomplish before we meet again? Focus on work that creates new dependencies or that other teams are waiting for.
3. Is anything blocking my team or slowing us down that other teams need to know about? Focus on cross-team blockers. Internal team blockers are handled in the team’s own Daily Scrum.
4. Are we about to create any problems for other teams? This is the most uniquely valuable SoS question. It surfaces risks before they become blockers. “We are changing the authentication API on Tuesday. Any team that depends on it needs to know now.”

SoS meeting time box and frequency:

• Time box: 15 to 60 minutes depending on the number of teams and complexity of dependencies
• Minimum: 15 minutes if meeting daily, following each team’s Daily Scrum
• Practical: 30 to 45 minutes for meetings held 2 to 3 times per week
• Frequency: Ken Schwaber’s original guidance was daily at 15 minutes. Most modern practitioners recommend 2 to 3 times per week at 30 to 45 minutes for non-daily SoS configurations
• Timing: Immediately after individual teams’ Daily Scrums, so ambassadors arrive with current information

Many teams leave Scrum of Scrums with conversations but no coordination outcomes.

A successful Scrum of Scrums should produce one or more of the following:

• Newly identified dependencies
• Clarified ownership for shared work
• Escalated cross-team impediments
• Integration testing actions
• Architectural decisions requiring follow-up
• Risk mitigation actions before sprint completion

If none of these outcomes emerge regularly, the meeting may have become a status update rather than a coordination event.

A useful retrospective question is:

“What dependency did Scrum of Scrums help us resolve this sprint that would otherwise have become a blocker?”

If teams struggle to answer that question, the format may need redesign.

Scrum of Scrums of Scrums (SoSoS): Scaling Beyond Multiple Teams

When an organization grows beyond 5 to 6 Scrum teams, a single Scrum of Scrums becomes crowded and difficult to manage. Organizations with 10 to 50+ teams introduce a hierarchical coordination structure called Scrum of Scrums of Scrums (SoSoS).

How SoSoS works:

• Teams 1 to 5 send ambassadors to SoS Group A
• Teams 6 to 10 send ambassadors to SoS Group B
• SoS Group A and SoS Group B each send one representative to the SoSoS
• The SoSoS coordinates program-level integration risks and escalated blockers

When to use SoSoS:

• More than 6 Scrum teams working on a connected program
• Program-level risks and architectural decisions need coordination across SoS groups
• Communication overhead in a single SoS becomes unmanageable

This tiered structure mirrors the organizational structure of large software programs without becoming bureaucratic. Each level retains the agile spirit: focus on alignment, blockers, and integration. For organizations implementing SAFe at scale, this structure corresponds to the SAFe Large Solution level above the ART. NextAgile’s agile at scale consulting covers both SoSoS and SAFe Large Solution configuration.

Scrum of Scrums vs SAFe ART Sync: Which to Use?

Both Scrum of Scrums and the SAFe ART Sync serve the same coordination function: synchronizing multiple agile teams working on a shared program. The choice depends on whether your organization has formally adopted SAFe.

Organizations using SAFe do not need to run Scrum of Scrums separately. The ART Sync replaces it at the program level. For organizations not yet on SAFe, Scrum of Scrums is the appropriate coordination mechanism for 2 to 5 teams.

Signs Your Scrum of Scrums Is Working

Many organizations continue running Scrum of Scrums because it exists on the calendar, not because it is creating measurable value.

The following indicators suggest the practice is working:

• Cross-Team Blockers Surface Earlier – Teams identify dependency risks before they delay sprint work.

• Fewer Integration Surprises – Teams discover compatibility issues during development rather than during release preparation.

• Faster Escalation Paths – Program-level impediments reach decision-makers sooner.

• Reduced Duplicate Work – Teams gain visibility into overlapping efforts and coordinate proactively.

• Better Predictability – Sprint commitments become more reliable because external dependencies are actively managed.

The goal is fewer surprises.

The 5 Scrum of Scrums Anti-Patterns

Anti-pattern 1: SoS becomes a status report to leadership

When managers attend or lead the SoS, ambassadors report status upward rather than coordinating laterally. The meeting loses its peer coordination function.

Fix: Keep the SoS ambassador-led. Scrum Masters attend as coaches; managers observe without participating.

Anti-pattern 2: Ambassadors do not share SoS outcomes with their teams

The SoS coordination value is lost if ambassadors do not relay decisions, dependencies, and risk information back to their teams within 30 minutes of the meeting.

Fix: Make “share SoS outcomes with the team” an explicit post-SoS action item for every ambassador, every meeting.

Anti-pattern 3: Fixed ambassadors regardless of sprint context

Sending the Scrum Master every week regardless of which work is highest-dependency means the wrong person often represents the team’s most critical coordination needs.

Fix: Rotate ambassadors based on who owns the sprint’s highest-dependency stories. The ambassador should be whoever knows the work most likely to affect other teams.

Anti-pattern 4: Problem-solving in the SoS

When complex cross-team problems are solved in the SoS meeting, the meeting grows beyond 30 to 45 minutes and attendance becomes burdensome.

Fix: Capture cross-team problems in the meeting. Schedule immediate post-SoS resolution meetings with only the relevant team members.

Anti-pattern 5: No SoS when things get busy

Teams skip the SoS when approaching release dates or when sprint pressure is high. This is precisely when cross-team coordination is most critical.

Fix: Treat the SoS as non-optional during high-dependency sprints. A 15-minute SoS when things are complicated is worth more than a 1-hour post-release incident review.

Scrum of Scrums Metrics: How to Measure Effectiveness

One of the biggest mistakes organizations make is measuring Scrum of Scrums by attendance rather than outcomes.

Useful metrics include:

Avoid measuring the below parameters because these measure activity:

• Number of attendees
• Number of discussion topics
• Meeting duration

Scrum of Scrums in Product vs Platform Teams

Not all Scrum of Scrums implementations look the same.

Product Team Environment

When multiple teams contribute features to a single customer-facing product, discussions typically focus on:

• Feature dependencies
• Release readiness
• Shared customer outcomes
• Product roadmap alignment

Platform Team Environment

When platform teams support multiple delivery teams, discussions often focus on:

• Shared services
• Infrastructure changes
• API versioning
• Security and compliance requirements

Understanding whether your teams are primarily product-oriented or platform-oriented helps determine what topics deserve the most attention in Scrum of Scrums.

Scrum of Scrums for Distributed Teams in India

For India-based engineering teams coordinating with global counterparts, Scrum of Scrums requires 3 specific adaptations:

IST-friendly scheduling: Schedule SoS during the 2 to 4 hour window where IST overlaps with both the US morning (for US East Coast: IST 6:30 to 9pm = EST 9am to 12pm) and the UK afternoon. This window constrains to roughly 11am to 1pm IST for India-US-UK coordination.

Async SoS for full time zone separation: When no overlap window exists (e.g., IST and US Pacific), use an async SoS format: each ambassador posts their 4 answers in a shared channel at the start of their local day. A designated SoS coordinator reviews all answers, identifies cross-team risks, and posts a dependency summary within 2 hours. Live SoS meetings happen twice per week for escalations.

Language and communication clarity: For distributed teams, the “about to create problems for other teams” question produces the highest value. Ask ambassadors to phrase this as specific technical facts: “Our team is merging the user service refactor on Thursday. The payment module depends on the user service API. Payment team, please test your integration on Wednesday.”

NextAgile’s agile transformation consulting has helped enterprise teams across India, Dubai, and the USA design distributed SoS structures that maintain coordination quality across time zones.

Conclusion

Scrum of Scrums is the most practical and widely adopted technique for coordinating multiple Scrum teams working on connected programs. It preserves individual team autonomy while creating a formal coordination mechanism for cross-team dependencies, integration risks, and shared blockers.

The key elements that make SoS effective are: the right ambassador (not always the Scrum Master), the right frequency (2 to 3 times per week at 30 to 45 minutes for most teams), the 4-question agenda (especially “are we about to create problems for other teams?”), and immediate information relay back to individual teams.

For enterprise organizations scaling beyond 5 teams, the SoSoS structure or SAFe ART Sync provides the coordination architecture that SoS alone cannot sustain. NextAgile’s agile consulting companies help organizations design the right coordination structure for their scale, team distribution, and delivery complexity. Contact us at consult@nextagile.ai .

Frequently Asked Questions

Q1. Is Scrum of Scrums part of the official Scrum framework?

No. The Scrum Guide does not mention Scrum of Scrums. It is a complementary scaling technique developed by Jeff Sutherland and Ken Schwaber alongside the Scrum framework in 1996. Because it is not in the Scrum Guide, organizations have significant flexibility in how they implement it. The Agile Alliance’s Glossary documents it as a widely-used agile practice, and the Scrum Alliance covers it as a scaling approach, but neither body formally certifies or mandates its structure.

Q2. How often should Scrum of Scrums meet?

Frequency depends on the density of cross-team dependencies. Jeff Sutherland’s original guidance was daily at 15 minutes. Most modern practitioners recommend 2 to 3 times per week at 30 to 45 minutes for teams not meeting daily. For teams with high daily dependency risk (shared APIs, integration-heavy sprints), daily SoS at 15 minutes is appropriate. For teams with lower dependency frequency, weekly SoS at 60 minutes is sufficient. The guiding principle: meet frequently enough that cross-team blockers surface before they consume a full sprint day.

Q3. Who should attend Scrum of Scrums?

One representative (the “ambassador”) from each Scrum team. The ambassador is not always the Scrum Master. The ideal ambassador is the team member with the deepest knowledge of the sprint’s highest-dependency work and the authority to make or quickly escalate decisions. For a sprint where the API team’s senior developer owns the shared service refactor, that developer should be the ambassador, not the Scrum Master. The Scrum Masters from each team may also attend as observers or facilitators without formally participating as ambassadors.

Q4. What is the difference between Scrum of Scrums and SAFe ART Sync?

Both events coordinate multiple agile teams working on a shared program. Scrum of Scrums is framework-agnostic and works with any combination of agile teams. SAFe ART Sync is a formally defined SAFe event with a prescribed 30-minute time box, specific attendees (all Scrum Masters and Product Managers), and a weekly cadence tied to the ART’s sprint and PI rhythm. Organizations using SAFe do not separately run Scrum of Scrums. Those not using SAFe use Scrum of Scrums for the same coordination function.

Q5. What are the 4 questions in a Scrum of Scrums meeting?

The 4 questions each ambassador answers are: (1) What has my team accomplished since we last met? (2) What will my team accomplish before we meet again? (3) Is anything blocking my team that other teams need to know about? (4) Are we about to create any problems for other teams? The fourth question is the most uniquely valuable to the SoS format. It proactively surfaces risks before they become cross-team blockers, which is the coordination failure that SoS was specifically designed to prevent.

Q6. How do you scale Scrum of Scrums for very large organizations?

Organizations with more than 5 to 6 Scrum teams use a nested structure called Scrum of Scrums of Scrums (SoSoS). Groups of 5 to 6 Scrum teams each run their own SoS. One representative from each SoS group then attends a higher-level SoSoS meeting that coordinates program-level risks and architectural decisions. This hierarchical structure scales indefinitely while maintaining the peer-coordination nature of each level. For organizations using SAFe, the Large Solution level provides a formally governed equivalent to SoSoS.

Q7. Does Scrum of Scrums replace the Daily Scrum?

No.

The Daily Scrum and Scrum of Scrums solve different problems.

The Daily Scrum helps a single Scrum Team inspect progress toward its Sprint Goal and adapt its plan for the next 24 hours.

Scrum of Scrums focuses on coordination between teams. It addresses cross-team dependencies, integration risks, and shared impediments that individual teams cannot resolve independently.

Replacing Daily Scrums with Scrum of Scrums removes local team coordination while failing to provide the detailed planning individual teams still require.

Q8. What is the ideal number of teams for a Scrum of Scrums?

Most experienced practitioners find that a single Scrum of Scrums works effectively for approximately two to five teams.

Beyond six teams, coordination overhead increases significantly. Discussions become broader, meeting duration expands, and participants lose visibility into all dependencies.

At that point, organizations typically introduce a Scrum of Scrums of Scrums (SoSoS), SAFe ART Sync, or another scaling coordination mechanism.

Anuj Ojha

Anuj Ojha is Co-Founder & Consulting Head at NextAgile. Anuj has designed & led multiple turnkey transformation journeys across industries, domains & geographies and has 16+ years of experience as an agile practitioner. He has worked with CXOs, CTOs & Key Leaders to translate their business objectives on the ground, contextualizing org transformations and creating buy-in across level, leading a team of coaches/consultants to implement agility across 150+ teams & trained more than 12k team members. Anuj’s core area of interest is business agility & working with leaders & teams to achieve long term sustainable, Agile culture & mindset.

See author's posts