When a product grows too large for one Scrum team, organizations split the work across multiple teams. That split solves a capacity problem. But it immediately creates a coordination problem. How do five or eight or twelve Scrum teams working on the same product stay synchronized? How do dependencies get resolved before they block a sprint? How does one team’s progress stay visible to the others?
Scrum of Scrums answers those questions. It is a coordination technique for scaling Scrum across multiple teams. It keeps cross-team work visible, surfaces blockers early, and prevents integration failures before they cost a release.
Table of contents
What is Scrum of Scrums?
Scrum of Scrums (SoS) is a scaled Agile coordination technique in which a representative from each Scrum team meets regularly to address cross-team dependencies, risks, and integration challenges. According to Scrum Alliance, it is “a method used to coordinate multiple Scrum teams working on the same product goals.” Jeff Sutherland and Ken Schwaber first implemented it in 1996 at IDX Systems (now GE Healthcare), where they needed to coordinate eight business units with multiple product lines.
Sutherland published the concept publicly in his 2001 article “Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies.” Scrum of Scrums is not part of the official Scrum Guide. It is a separate coordination practice that teams adopt when single-team Scrum is not sufficient.
Key Takeaways
- Scrum of Scrums (SoS) coordinates multiple Scrum teams working toward a common product goal.
- Jeff Sutherland and Ken Schwaber first implemented it at IDX Systems (now GE Healthcare) in 1996 to coordinate eight business units with multiple product lines per unit.
- Sutherland first published the concept in his 2001 article “Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies,” according to Atlassian and Scrum patterns documentation.
- Scrum of Scrums is not part of the official Scrum Guide. It is a community-developed scaling practice.
- Each Scrum team sends one representative — called an ambassador — to the Scrum of Scrums meeting. The ambassador is often the Scrum Master but can be any team member best positioned to discuss dependencies.
- Each ambassador answers four questions in the meeting, mirroring the four daily standup questions but focused on cross-team impact.
- Meetings run daily, twice a week, or weekly depending on team size and integration risk.
- Scrum of Scrums has influenced larger scaling frameworks including SAFe and LeSS. But it is lighter and less prescriptive than either.
Public, Onsite, Virtual, and Online Six Sigma Certification Training!
- We are accredited by the IASSC.
- Live Public Training at 52 Sites.
- Live Virtual Training.
- Onsite Training (at your organization).
- Interactive Online (self-paced) training,
The Origin of Scrum of Scrums
Jeff Sutherland and Ken Schwaber created the Scrum framework. They published it formally at the OOPSLA conference in 1995 and in a paper in 1996.
At that same time, Sutherland was serving as Senior Vice-President of Engineering at IDX Systems, now part of GE Healthcare. Ken Schwaber worked alongside him as a consultant. They faced a specific coordination problem. The organization had eight business units. Each business unit had multiple product lines. Each product had its own Scrum team.
According to the Scrum Patterns documentation hosted at scrumplop.org, Sutherland and Schwaber found that separate Scrum teams for each business unit “impeded workflow within and across business units.” So they experimented. They gathered all product teams together and created what they called a “Scrum of Scrums” — a meta-team formed from the individual teams, designed to synchronize their work.
Every product had to deliver to the market on a release cycle of three months or less. All products had to be fully integrated, upgraded, and deployed every six months to support regional healthcare providers including the Stanford Health System. The Scrum of Scrums gave them the coordination structure to achieve this.
Sutherland published the experience publicly in 2001. His article in the Cutter IT Journal, “Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies,” mentioned Scrum of Scrums for the first time in print. Atlassian confirms this directly: the 2001 article is the first public documentation of the method.
Also Read: Large Scale Scrum: How to Scale Agile Without the Bloat
What Scrum of Scrums Is and Is Not
Understanding what Scrum of Scrums is — and what it is not — prevents two common misapplications.
Scrum of Scrums IS:
- A coordination technique for multiple Scrum teams working on the same product or set of related products
- A lightweight synchronization meeting where team ambassadors share cross-team status and resolve dependencies
- An approach that respects individual team autonomy while maintaining overall alignment
- A practice that teams adopt and adapt to their context — it is not prescriptive
Scrum of Scrums IS NOT:
- Part of the official Scrum Guide (Agile Academy confirms this explicitly: “Scrum of Scrums is one possible approach, not part of the official Scrum Guide”)
- A management hierarchy or governance layer over the individual teams
- A substitute for the Daily Scrum within each individual team
- The same thing as Scrum at Scale (Scrum@Scale), which is a separate and more comprehensive scaling framework
Scrum@Scale was launched formally in 2018 as a product of Sutherland and Scrum Inc. Nimblework notes that both “Scrum of Scrums” and “Scrum@Scale” are associated with Sutherland, which causes confusion. The key difference: Scrum of Scrums only coordinates teams. Scrum@Scale attempts to reduce decision-making time across the entire organization. Scrum of Scrums is the simpler, more focused option.
How Scrum of Scrums Works
The Ambassador Role
Each Scrum team selects one member to attend the Scrum of Scrums meeting. Scrum Alliance describes this person as a representative “designated to join a regular cross-team meeting — this might be the Scrum master, a technical lead, or another team member, depending on who is best positioned to understand and address the dependencies involved.”
The ambassador does not make decisions for the team. They carry information between the team and the Scrum of Scrums. They bring blockers from the team to the meeting. They carry decisions and information back to the team afterward.
Some organizations rotate the ambassador role so more team members develop cross-team awareness. Others keep the same ambassador throughout a program increment to build consistency. Both approaches work. The right choice depends on the team’s structure and the complexity of the dependencies being managed.
Meeting Frequency and Duration
Scrum of Scrums meetings are more flexible than the 15-minute Daily Scrum. Monday.com confirms that meetings are “typically held daily, twice a week, or at least once a week” depending on the level of integration risk and the number of teams involved.
During high-risk integration periods — when multiple teams must combine their work for a release — daily meetings make sense. During stable sprint periods with fewer dependencies, twice-weekly or weekly meetings are sufficient.
Meeting duration is not fixed at 15 minutes. The meeting runs until the necessary cross-team coordination has happened. In practice, well-run Scrum of Scrums meetings finish in 15 to 30 minutes when teams come prepared. They run longer when ambassadors arrive without prior preparation or when unresolved dependencies dominate the agenda.
Also Read: Kanban vs. Scrum: How to Choose the Best Agile Methodology?
The Four Scrum of Scrums Questions
Each ambassador answers four questions at every meeting. The questions mirror the structure of the Daily Scrum within a team but focus on cross-team impact rather than individual progress.
Question 1: What has your team completed since we last met?
This question shares progress visible across team boundaries. It surfaces completed work that other teams may depend on. Other ambassadors learn what is now available to integrate or build upon.
Question 2: What will your team complete before we meet again?
This question signals upcoming deliverables. Other teams can plan their integration activities around these commitments. It makes near-term work predictable across team boundaries.
Question 3: What is getting in your team’s way?
This is the blocker question. Anything preventing the team from completing its planned work appears here. Blockers that cross team boundaries — a shared dependency, a missing interface, an unresolved architectural decision — become visible at the Scrum of Scrums level where they can be resolved.
Question 4: Are you about to put something in another team’s way?
This is the most forward-looking question. It asks ambassadors to identify work that will affect another team before that effect occurs. Marutitech describes this as the core preventive function of Scrum of Scrums: “teams using Scrum of Scrums can identify and resolve cross-team dependencies early in the development cycle. This proactive approach prevents bottlenecks and ensures smooth project progression.”
Questions 3 and 4 produce the most value. They surface blockers and risks before they become incidents, giving the Scrum of Scrums the opportunity to resolve them during the sprint rather than after.
When to Use Scrum of Scrums
Scrum of Scrums becomes necessary when a single Scrum team can no longer handle the product’s scope. Standard Scrum works best with teams of three to nine people. Atlassian and monday.com both confirm the standard: a Scrum team typically consists of ten or fewer people. Research has shown that smaller teams communicate more efficiently and perform better than larger ones.
When the product requires more people, the organization splits into multiple teams. Scrum of Scrums coordinates those teams. The threshold for introducing it is not a specific team count. It is the moment when cross-team dependencies are causing delays or when integration failures are appearing at sprint review.
Organizations working across geographies and time zones benefit particularly from Scrum of Scrums. Marutitech identifies distributed teams as a key use case: the technique “provides a means for teams to synchronize their work, communicate any issues or delays, and coordinate planning activities” regardless of location.
Scrum of Scrums vs. Other Scaling Frameworks
Scrum of Scrums is one of several approaches for scaling Agile. Each takes a different position on structure, prescriptiveness, and scope.
| Framework | Scale | Prescriptiveness | Best For |
| Scrum of Scrums | Multiple teams on one product | Low | Lightweight cross-team coordination |
| SAFe | Enterprise | High | Large organizations needing structured governance |
| LeSS | Multiple teams, one product | Medium | Organizations wanting minimal additional structure |
| Nexus | 3 to 9 Scrum teams | Medium | Teams needing a formal integration framework |
| Scrum@Scale | Enterprise | Medium-High | Organizations scaling both delivery and organizational decision-making |
The Knowledge Academy confirms that Scrum of Scrums has influenced both SAFe and LeSS. Organizations that want lighter coordination adopt Scrum of Scrums. Organizations that need broader transformation adopt one of the enterprise frameworks.
The right choice depends on the organization’s size, the number of teams, the level of integration complexity, and the appetite for structural change. Scrum of Scrums is the right starting point for organizations new to multi-team coordination. It requires minimal new roles, minimal new ceremonies, and zero new tooling.
Running an Effective Scrum of Scrums: Practical Guidance
Several practices distinguish effective Scrum of Scrums meetings from ones that become status reports.
Keep the focus on dependencies, not status. Status reports belong in team dashboards. The Scrum of Scrums exists specifically to surface and resolve cross-team dependencies. If the meeting becomes a round of status updates with no action items, it has lost its purpose.
Give ambassadors authority to make commitments. An ambassador who must check with the team before agreeing to anything creates a bottleneck. Ambassadors should understand their team’s capacity and priorities well enough to make reasonable cross-team commitments on the spot.
Record blockers and assign owners immediately. Every blocker surfaced at a Scrum of Scrums meeting needs an owner and a resolution timeline before the meeting ends. Unassigned blockers remain unresolved.
Use a visual board. A simple board showing each team’s sprint progress, current blockers, and upcoming delivery commitments makes the meeting more efficient. Ambassadors can update the board before the meeting, reducing the time spent in verbal status reporting.
Review the board before speaking. Ambassadors who review cross-team status before the meeting can focus their speaking time on issues that require group resolution rather than broadcasting information already visible on the board.
Scrum of Scrums and Six Sigma
Six Sigma and Scrum of Scrums address different problems but serve the same organizational goal: reliable, high-quality delivery.
Six Sigma uses the DMAIC framework to reduce defects and process variation. Scrum of Scrums coordinates delivery across multiple teams. In organizations running both, the combination is natural.
A Six Sigma Lean or Black Belt practitioner working in an Agile environment may identify recurring cross-team integration failures as a quality problem.
The DMAIC Define phase would scope it, the Measure phase would quantify the defect rate (blocked sprints, failed integrations, late releases), the Analyze phase would confirm root causes (poor dependency visibility, late blocker identification, insufficient coordination), and the Improve phase might recommend or redesign the Scrum of Scrums cadence to address the root cause.
Conversely, Six Sigma’s waste elimination principles — specifically the waste of waiting and the waste of defects — directly support the Scrum of Scrums objective. A sprint blocked by a cross-team dependency creates waiting waste. An integration failure creates defect waste. Scrum of Scrums prevents both.
Understanding Scrum of Scrums and its relationship to Six Sigma’s continuous improvement principles is increasingly valuable for practitioners working in technology, product development, and any industry running Agile alongside Lean Six Sigma.
Frequently Asked Questions: Scrum of Scrums
Q: What is Scrum of Scrums?
A: Scrum of Scrums is a scaled Agile coordination technique in which a representative from each Scrum team meets regularly to address cross-team dependencies, blockers, and integration challenges. According to Scrum Alliance, it is “a method used to coordinate multiple Scrum teams working on the same product goals.” Jeff Sutherland and Ken Schwaber first implemented it in 1996 at IDX Systems (now GE Healthcare) to coordinate eight business units with multiple product lines. It is not part of the official Scrum Guide.
Q: Who created Scrum of Scrums?
A: Jeff Sutherland and Ken Schwaber created Scrum of Scrums. They first implemented it in 1996 at IDX Systems while coordinating eight business units with multiple product lines. The Scrum Patterns documentation confirms Sutherland was Senior Vice-President of Engineering at the time and Schwaber worked as a consultant. Sutherland first published the concept publicly in 2001 in his article “Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies” in the Cutter IT Journal.
Q: What are the four questions asked in a Scrum of Scrums meeting?
A: Each team ambassador answers four questions at every Scrum of Scrums meeting. Question 1: What has your team completed since we last met? Question 2: What will your team complete before we meet again? Question 3: What is getting in your team’s way? Question 4: Are you about to put something in another team’s way? Questions 3 and 4 produce the most value by surfacing blockers and risks before they disrupt other teams’ sprints.
Q: How often should a Scrum of Scrums meet?
A: Scrum of Scrums meeting frequency depends on integration risk and team count. Monday.com confirms that meetings are “typically held daily, twice a week, or at least once a week.” Daily meetings suit high-risk integration periods. Weekly or twice-weekly meetings suit stable sprint periods with fewer dependencies. Meeting duration is not fixed at 15 minutes — it runs until the necessary cross-team coordination is complete.
Q: What is the difference between Scrum of Scrums and Scrum@Scale?
A: Scrum of Scrums coordinates multiple teams working on one product. It is lightweight and team-focused. Scrum@Scale is a more comprehensive framework launched formally in 2018 by Jeff Sutherland and Scrum Inc. It attempts to scale both delivery and organizational decision-making across the entire enterprise. Nimblework notes that both are associated with Sutherland, which creates confusion, but Scrum@Scale is far more extensive in scope than Scrum of Scrums.
Q: Is Scrum of Scrums part of the Scrum Guide?
A: No. Agile Academy confirms that “Scrum of Scrums is one possible approach, not part of the official Scrum Guide. Teams are encouraged to find the coordination method that best fits their context.” Scrum of Scrums is a community-developed scaling practice that grew from practical experience. It sits outside the formal Scrum framework definition and does not carry the same prescriptive authority as the roles, events, and artifacts defined in the Scrum Guide.
Six Sigma Training for Agile Environments
Practitioners working in Agile organizations benefit from understanding how Six Sigma’s structured problem-solving approach complements Agile delivery. Green Belt and Black Belt training builds the statistical and process improvement skills that make quality improvements sustainable — regardless of whether the team uses DMAIC, Scrum, or a combination of both.
At Six Sigma Development Solutions Inc., our Green Belt and Black Belt programs cover Lean Six Sigma tools in the context of modern operational environments, including organizations that run Agile delivery frameworks alongside continuous improvement programs.
We offer training in three formats:
- Onsite training — delivered at your facility, using your real processes and your team’s operational context.
- Live virtual training — instructor-led sessions online with real-time interaction and cross-industry examples.
- Online training — self-paced Green Belt and Black Belt certification programs on your own schedule.
Explore our Six Sigma training programs or contact our team to find the right program for your goals.
About Six Sigma Development Solutions, Inc.
Six Sigma Development Solutions, Inc. offers onsite, public, and virtual Lean Six Sigma certification training. We are an Accredited Training Organization by the IASSC (International Association of Six Sigma Certification). We offer Lean Six Sigma Green Belt, Black Belt, and Yellow Belt, as well as LEAN certifications.
Book a Call and Let us know how we can help meet your training needs.
