{"id":8262,"date":"2026-06-15T09:48:49","date_gmt":"2026-06-15T09:48:49","guid":{"rendered":"https:\/\/nextagile.ai\/blogs\/?p=8262"},"modified":"2026-06-15T09:48:49","modified_gmt":"2026-06-15T09:48:49","slug":"scrum-of-scrums","status":"publish","type":"post","link":"https:\/\/nextagile.ai\/blogs\/agile\/scrum-of-scrums\/","title":{"rendered":"Scrum of Scrums: Definition, Agenda, Roles, and Enterprise Scaling Guide (2026)"},"content":{"rendered":"<h2>Key Highlights<\/h2>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">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.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">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).<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">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.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">In SAFe, the ART Sync event serves a similar coordination function to Scrum of Scrums but is specifically designed for multi-ART environments.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">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.<\/span><\/li>\n<\/ul>\n<h2>Introduction<\/h2>\n<p><span style=\"font-weight: 400;\">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 <\/span><a href=\"https:\/\/nextagile.ai\/blogs\/agile\/daily-scrum-meeting\/\"><span style=\"font-weight: 400;\">Daily Scrum<\/span><\/a><span style=\"font-weight: 400;\"> concept up to the program level without making the Daily Scrum itself unwieldy by adding too many participants.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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&#8217;s autonomy.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Scrum of Scrums is not part of the <\/span><a href=\"https:\/\/www.agilealliance.org\/glossary\/scrum-of-scrums\" rel=\"nofollow noopener\" target=\"_blank\"><b>official Scrum<\/b><\/a><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<h2>What Is Scrum of Scrums?<\/h2>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><b>The core mechanics:<\/b><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Each Scrum team selects one representative (called the &#8220;ambassador&#8221;) to attend the Scrum of Scrums meeting<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Ambassadors meet at a regular cadence to share progress, surface cross-team blockers, and coordinate dependencies<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">The Scrum of Scrums meeting follows a structured 4-question agenda derived from the Daily Scrum<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Each Scrum team continues to run its own internal Daily Scrum independently<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Most organizations do not introduce Scrum of Scrums because they are scaling successfully. They introduce it because coordination has already started to break down.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Scrum of Scrums exists to solve three scaling problems:<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3>Dependency Visibility<\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Team A cannot complete its work because Team B owns a shared API. Without a coordination mechanism, that dependency often surfaces too late.<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\">\n<h3>Integration Risk<\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Individual teams may successfully complete their sprint goals while the integrated product remains unstable or incomplete.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3>Decision Synchronization<\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The purpose of Scrum of Scrums is not reporting status. Its purpose is reducing coordination cost while preserving team autonomy.<\/span><\/p>\n<p><b>When you need Scrum of Scrums:<\/b><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">You have 2 or more Scrum teams working on connected features or a shared product<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Cross-team dependencies are creating sprint blockers for individual teams<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Integration issues between teams are surfacing late in the sprint<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Communication gaps are causing duplicated work or conflicting decisions<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Many organizations underestimate how much delivery time is lost to unmanaged dependencies.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A team blocked for two days waiting on another team&#8217;s API may appear productive because individual stories remain in progress. At the program level, however, delivery throughput slows significantly.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Research from the book <\/span><i><span style=\"font-weight: 400;\">Accelerate<\/span><\/i><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A well-run Scrum of Scrums cannot eliminate dependencies, but it can dramatically reduce the time teams spend discovering and resolving them.<\/span><\/p>\n<p><b>When Scrum of Scrums is NOT the right solution:<\/b><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">You have 1 Scrum team. Use the Daily Scrum instead.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">You have 10+ Scrum teams. Consider SAFe <\/span><a href=\"https:\/\/scaledagile.com\" rel=\"nofollow noopener\" target=\"_blank\"><b>ART Sync<\/b><\/a><span style=\"font-weight: 400;\"> or a SoSoS structure instead.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Your teams work on completely independent products with no integration points. No coordination meeting needed.<\/span><\/li>\n<\/ul>\n<h2>Scrum of Scrums Roles<\/h2>\n<h3>The Ambassador<\/h3>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">One of the most common reasons Scrum of Scrums becomes ineffective is ambassador selection based on hierarchy rather than relevance.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Organizations frequently default to sending:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">The Scrum Master<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">The team manager<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">The most senior person<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Instead of sending:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">The person closest to the dependency<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">The person who owns the affected work<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">The person capable of making or escalating decisions quickly<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">A useful rule is simple:<\/span><\/p>\n<p><b>The ambassador should be the person most likely to answer dependency questions from another team without saying, &#8220;I&#8217;ll need to check and get back to you.&#8221;<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The role may rotate sprint by sprint depending on where the highest coordination risk exists.<\/span><\/p>\n<p><b>Who makes the best ambassador:<\/b><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">A team member with deep current knowledge of the team&#8217;s sprint work and blockers<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Someone with decision-making authority or direct access to decision-makers<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Not necessarily the Scrum Master (though Scrum Masters often attend by default)<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">The right ambassador changes based on the sprint&#8217;s work. A senior developer with ownership of the current sprint&#8217;s highest-dependency stories is often more valuable than the Scrum Master.<\/span><\/li>\n<\/ul>\n<p><b>The ambassador&#8217;s responsibilities:<\/b><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Attend the SoS meeting prepared with the team&#8217;s status on the 4 questions<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Represent the team&#8217;s blockers, risks, and dependencies accurately<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Return to the team after the SoS and share decisions and coordination outcomes<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Escalate issues that cannot be resolved at the SoS level<\/span><\/li>\n<\/ul>\n<h3>The Scrum of Scrums Master<\/h3>\n<p><span style=\"font-weight: 400;\">For larger SoS configurations (4+ teams), some organizations designate a Scrum of Scrums Master\u00a0 a role analogous to the Scrum Master but at the program coordination level. The SoS Master:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Facilitates the Scrum of Scrums meeting<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Tracks cross-team impediments and ensures resolution<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Escalates program-level blockers to leadership or the Product Manager<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Connects the SoS coordination outcomes to individual team sprint planning<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">In SAFe, the Release Train Engineer (RTE) fulfills this role for the Agile Release Train. NextAgile&#8217;s<\/span><a href=\"https:\/\/nextagile.ai\/safe-consulting-services\/\"> <span style=\"font-weight: 400;\">SAFe consulting services<\/span><\/a><span style=\"font-weight: 400;\"> include RTE coaching and PI Planning facilitation as core delivery components.<\/span><\/p>\n<h2>The Scrum of Scrums Meeting Agenda: The 4 Questions<\/h2>\n<p><span style=\"font-weight: 400;\">The Scrum of Scrums meeting follows a 4-question agenda adapted from the Daily Scrum&#8217;s 3-question format. The fourth question is the critical addition that distinguishes SoS from a simple multi-team standup.<\/span><\/p>\n<p><b>The 4 SoS questions each ambassador answers:<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>What has my team accomplished since we last met?<\/b><span style=\"font-weight: 400;\"> Focus on completed work that other teams depend on or that represents integration risk.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>What will my team accomplish before we meet again?<\/b><span style=\"font-weight: 400;\"> Focus on work that creates new dependencies or that other teams are waiting for.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Is anything blocking my team or slowing us down that other teams need to know about?<\/b><span style=\"font-weight: 400;\"> Focus on cross-team blockers. Internal team blockers are handled in the team&#8217;s own Daily Scrum.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Are we about to create any problems for other teams?<\/b><span style=\"font-weight: 400;\"> This is the most uniquely valuable SoS question. It surfaces risks before they become blockers. &#8220;We are changing the authentication API on Tuesday. Any team that depends on it needs to know now.&#8221;<\/span><\/li>\n<\/ol>\n<p><b>SoS meeting time box and frequency:<\/b><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Time box:<\/b><span style=\"font-weight: 400;\"> 15 to 60 minutes depending on the number of teams and complexity of dependencies<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Minimum:<\/b><span style=\"font-weight: 400;\"> 15 minutes if meeting daily, following each team&#8217;s Daily Scrum<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Practical:<\/b><span style=\"font-weight: 400;\"> 30 to 45 minutes for meetings held 2 to 3 times per week<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Frequency:<\/b><span style=\"font-weight: 400;\"> Ken Schwaber&#8217;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<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Timing:<\/b><span style=\"font-weight: 400;\"> Immediately after individual teams&#8217; Daily Scrums, so ambassadors arrive with current information<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Many teams leave Scrum of Scrums with conversations but no coordination outcomes.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A successful Scrum of Scrums should produce one or more of the following:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Newly identified dependencies<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Clarified ownership for shared work<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Escalated cross-team impediments<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Integration testing actions<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Architectural decisions requiring follow-up<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Risk mitigation actions before sprint completion<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">If none of these outcomes emerge regularly, the meeting may have become a status update rather than a coordination event.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A useful retrospective question is:<\/span><\/p>\n<p><i><span style=\"font-weight: 400;\">&#8220;What dependency did Scrum of Scrums help us resolve this sprint that would otherwise have become a blocker?&#8221;<\/span><\/i><\/p>\n<p><span style=\"font-weight: 400;\">If teams struggle to answer that question, the format may need redesign.<\/span><\/p>\n<h2>Scrum of Scrums of Scrums (SoSoS): Scaling Beyond Multiple Teams<\/h2>\n<p><span style=\"font-weight: 400;\">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).<\/span><\/p>\n<p><b>How SoSoS works:<\/b><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Teams 1 to 5 send ambassadors to SoS Group A<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Teams 6 to 10 send ambassadors to SoS Group B<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">SoS Group A and SoS Group B each send one representative to the SoSoS<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">The SoSoS coordinates program-level integration risks and escalated blockers<\/span><\/li>\n<\/ul>\n<p><b>When to use SoSoS:<\/b><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">More than 6 Scrum teams working on a connected program<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Program-level risks and architectural decisions need coordination across SoS groups<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Communication overhead in a single SoS becomes unmanageable<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">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&#8217;s<\/span><a href=\"https:\/\/nextagile.ai\/agile-consulting-services\/\"> <span style=\"font-weight: 400;\">agile at scale consulting<\/span><\/a><span style=\"font-weight: 400;\"> covers both SoSoS and SAFe Large Solution configuration.<\/span><\/p>\n<h2>Scrum of Scrums vs SAFe ART Sync: Which to Use?<\/h2>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<table>\n<tbody>\n<tr>\n<td><b>Dimension<\/b><\/td>\n<td><b>Scrum of Scrums<\/b><\/td>\n<td><b>SAFe ART Sync<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Framework requirement<\/span><\/td>\n<td><span style=\"font-weight: 400;\">None\u00a0 works with any agile approach<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Requires SAFe adoption<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Formality<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Flexible\u00a0 teams design the structure<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Defined by SAFe framework<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Attendees<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Team ambassadors (rotating or fixed)<\/span><\/td>\n<td><span style=\"font-weight: 400;\">All Scrum Masters + Product Managers<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Duration<\/span><\/td>\n<td><span style=\"font-weight: 400;\">15 to 60 minutes<\/span><\/td>\n<td><span style=\"font-weight: 400;\">30 minutes (standard SAFe time box)<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Frequency<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Daily, 2-3x\/week, or weekly based on context<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Weekly<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Connection to PI Planning<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Not required<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Integral to SAFe PI rhythm<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Governance<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Team-defined<\/span><\/td>\n<td><span style=\"font-weight: 400;\">SAFe-prescribed<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Best for<\/span><\/td>\n<td><span style=\"font-weight: 400;\">2 to 5 teams, no formal scaling framework<\/span><\/td>\n<td><span style=\"font-weight: 400;\">5+ teams in a formal SAFe ART<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<h2>Signs Your Scrum of Scrums Is Working<\/h2>\n<p><span style=\"font-weight: 400;\">Many organizations continue running Scrum of Scrums because it exists on the calendar, not because it is creating measurable value.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The following indicators suggest the practice is working:<\/span><b><\/b><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-8264 size-full\" src=\"https:\/\/nextagile.ai\/blogs\/wp-content\/uploads\/2026\/06\/Signs-Your-Scrum-of-Scrums-Is-Working.png\" alt=\"Signs Your Scrum of Scrums Is Working\" width=\"1200\" height=\"800\" title=\"\" srcset=\"https:\/\/nextagile.ai\/blogs\/wp-content\/uploads\/2026\/06\/Signs-Your-Scrum-of-Scrums-Is-Working.png 1200w, https:\/\/nextagile.ai\/blogs\/wp-content\/uploads\/2026\/06\/Signs-Your-Scrum-of-Scrums-Is-Working-300x200.png 300w, https:\/\/nextagile.ai\/blogs\/wp-content\/uploads\/2026\/06\/Signs-Your-Scrum-of-Scrums-Is-Working-1024x683.png 1024w, https:\/\/nextagile.ai\/blogs\/wp-content\/uploads\/2026\/06\/Signs-Your-Scrum-of-Scrums-Is-Working-768x512.png 768w, https:\/\/nextagile.ai\/blogs\/wp-content\/uploads\/2026\/06\/Signs-Your-Scrum-of-Scrums-Is-Working-600x400.png 600w, https:\/\/nextagile.ai\/blogs\/wp-content\/uploads\/2026\/06\/Signs-Your-Scrum-of-Scrums-Is-Working-150x100.png 150w\" sizes=\"auto, (max-width: 1200px) 100vw, 1200px\" \/><\/p>\n<ul>\n<li aria-level=\"1\"><b>Cross-Team Blockers Surface Earlier &#8211; <\/b><span style=\"font-weight: 400;\">Teams identify dependency risks before they delay sprint work.<\/span><\/li>\n<\/ul>\n<ul>\n<li aria-level=\"1\"><b>Fewer Integration Surprises &#8211; <\/b><span style=\"font-weight: 400;\">Teams discover compatibility issues during development rather than during release preparation.<\/span><\/li>\n<\/ul>\n<ul>\n<li aria-level=\"1\"><b>Faster Escalation Paths &#8211; <\/b><span style=\"font-weight: 400;\">Program-level impediments reach decision-makers sooner.<\/span><\/li>\n<\/ul>\n<ul>\n<li aria-level=\"1\"><b>Reduced Duplicate Work &#8211; <\/b><span style=\"font-weight: 400;\">Teams gain visibility into overlapping efforts and coordinate proactively.<\/span><\/li>\n<\/ul>\n<ul>\n<li aria-level=\"1\"><b>Better Predictability &#8211; <\/b><span style=\"font-weight: 400;\">Sprint commitments become more reliable because external dependencies are actively managed.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">The goal is fewer surprises.<\/span><\/p>\n<h2>The 5 Scrum of Scrums Anti-Patterns<\/h2>\n<p><b>Anti-pattern 1: SoS becomes a status report to leadership<\/b><\/p>\n<p><span style=\"font-weight: 400;\">When managers attend or lead the SoS, ambassadors report status upward rather than coordinating laterally. The meeting loses its peer coordination function.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Fix: Keep the SoS ambassador-led. Scrum Masters attend as coaches; managers observe without participating.<\/span><\/p>\n<p><b>Anti-pattern 2: Ambassadors do not share SoS outcomes with their teams<\/b><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Fix: Make &#8220;share SoS outcomes with the team&#8221; an explicit post-SoS action item for every ambassador, every meeting.<\/span><\/p>\n<p><b>Anti-pattern 3: Fixed ambassadors regardless of sprint context<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Sending the Scrum Master every week regardless of which work is highest-dependency means the wrong person often represents the team&#8217;s most critical coordination needs.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Fix: Rotate ambassadors based on who owns the sprint&#8217;s highest-dependency stories. The ambassador should be whoever knows the work most likely to affect other teams.<\/span><\/p>\n<p><b>Anti-pattern 4: Problem-solving in the SoS<\/b><\/p>\n<p><span style=\"font-weight: 400;\">When complex cross-team problems are solved in the SoS meeting, the meeting grows beyond 30 to 45 minutes and attendance becomes burdensome.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Fix: Capture cross-team problems in the meeting. Schedule immediate post-SoS resolution meetings with only the relevant team members.<\/span><\/p>\n<p><b>Anti-pattern 5: No SoS when things get busy<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Teams skip the SoS when approaching release dates or when sprint pressure is high. This is precisely when cross-team coordination is most critical.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<h2>Scrum of Scrums Metrics: How to Measure Effectiveness<\/h2>\n<p><span style=\"font-weight: 400;\">One of the biggest mistakes organizations make is measuring Scrum of Scrums by attendance rather than outcomes.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Useful metrics include:<\/span><\/p>\n<table>\n<tbody>\n<tr>\n<td><b>Metric<\/b><\/td>\n<td><b>Why It Matters<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Cross-team blockers identified<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Measures visibility<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Cross-team blockers resolved<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Measures effectiveness<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Dependency resolution lead time<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Measures responsiveness<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Integration defects discovered before release<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Measures coordination quality<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Escalated program risks resolved<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Measures organizational support<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Sprint delays caused by dependencies<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Measures business impact<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><span style=\"font-weight: 400;\">Avoid measuring the below parameters because these measure activity:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Number of attendees<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Number of discussion topics<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Meeting duration<\/span><\/li>\n<\/ul>\n<h2>Scrum of Scrums in Product vs Platform Teams<\/h2>\n<p><span style=\"font-weight: 400;\">Not all Scrum of Scrums implementations look the same.<\/span><\/p>\n<p><b>Product Team Environment<\/b><\/p>\n<p><span style=\"font-weight: 400;\">When multiple teams contribute features to a single customer-facing product, discussions typically focus on:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Feature dependencies<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Release readiness<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Shared customer outcomes<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Product roadmap alignment<\/span><\/li>\n<\/ul>\n<p><b>Platform Team Environment<\/b><\/p>\n<p><span style=\"font-weight: 400;\">When platform teams support multiple delivery teams, discussions often focus on:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Shared services<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Infrastructure changes<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">API versioning<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Security and compliance requirements<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Understanding whether your teams are primarily product-oriented or platform-oriented helps determine what topics deserve the most attention in Scrum of Scrums.<\/span><\/p>\n<h2>Scrum of Scrums for Distributed Teams in India<\/h2>\n<p><span style=\"font-weight: 400;\">For India-based engineering teams coordinating with global counterparts, Scrum of Scrums requires 3 specific adaptations:<\/span><\/p>\n<p><b>IST-friendly scheduling:<\/b><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<p><b>Async SoS for full time zone separation:<\/b><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<p><b>Language and communication clarity:<\/b><span style=\"font-weight: 400;\"> For distributed teams, the &#8220;about to create problems for other teams&#8221; question produces the highest value. Ask ambassadors to phrase this as specific technical facts: &#8220;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.&#8221;<\/span><\/p>\n<p><span style=\"font-weight: 400;\">NextAgile&#8217;s<\/span><a href=\"https:\/\/nextagile.ai\/agile-transformation-consulting\/\"> <span style=\"font-weight: 400;\">agile transformation consulting<\/span><\/a><span style=\"font-weight: 400;\"> has helped enterprise teams across India, Dubai, and the USA design distributed SoS structures that maintain coordination quality across time zones.<\/span><\/p>\n<h2>Conclusion<\/h2>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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 &#8220;are we about to create problems for other teams?&#8221;), and immediate information relay back to individual teams.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">For enterprise organizations scaling beyond 5 teams, the SoSoS structure or SAFe ART Sync provides the coordination architecture that SoS alone cannot sustain. NextAgile&#8217;s<\/span><a href=\"https:\/\/nextagile.ai\/agile-consulting-services\/\"> <span style=\"font-weight: 400;\">agile consulting companies<\/span><\/a><span style=\"font-weight: 400;\"> help organizations design the right coordination structure for their scale, team distribution, and delivery complexity. Contact us at <\/span><a href=\"mailto:consult@nextagile.ai\"><span style=\"font-weight: 400;\">consult@nextagile.ai<\/span><\/a><span style=\"font-weight: 400;\"> .<\/span><\/p>\n<h2>Frequently Asked Questions<\/h2>\n<h3>Q1. Is Scrum of Scrums part of the official Scrum framework?<\/h3>\n<p><span style=\"font-weight: 400;\">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&#8217;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.<\/span><\/p>\n<h3>Q2. How often should Scrum of Scrums meet?<\/h3>\n<p><span style=\"font-weight: 400;\">Frequency depends on the density of cross-team dependencies. Jeff Sutherland&#8217;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.<\/span><\/p>\n<h3>Q3. Who should attend Scrum of Scrums?<\/h3>\n<p><span style=\"font-weight: 400;\">One representative (the &#8220;ambassador&#8221;) 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&#8217;s highest-dependency work and the authority to make or quickly escalate decisions. For a sprint where the API team&#8217;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.<\/span><\/p>\n<h3>Q4. What is the difference between Scrum of Scrums and SAFe ART Sync?<\/h3>\n<p><span style=\"font-weight: 400;\">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&#8217;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.<\/span><\/p>\n<h3>Q5. What are the 4 questions in a Scrum of Scrums meeting?<\/h3>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<h3>Q6. How do you scale Scrum of Scrums for very large organizations?<\/h3>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<h3>Q7. Does Scrum of Scrums replace the Daily Scrum?<\/h3>\n<p><span style=\"font-weight: 400;\">No.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The Daily Scrum and Scrum of Scrums solve different problems.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The Daily Scrum helps a single Scrum Team inspect progress toward its Sprint Goal and adapt its plan for the next 24 hours.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Scrum of Scrums focuses on coordination between teams. It addresses cross-team dependencies, integration risks, and shared impediments that individual teams cannot resolve independently.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Replacing Daily Scrums with Scrum of Scrums removes local team coordination while failing to provide the detailed planning individual teams still require.<\/span><\/p>\n<h3>Q8. What is the ideal number of teams for a Scrum of Scrums?<\/h3>\n<p><span style=\"font-weight: 400;\">Most experienced practitioners find that a single Scrum of Scrums works effectively for approximately two to five teams.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Beyond six teams, coordination overhead increases significantly. Discussions become broader, meeting duration expands, and participants lose visibility into all dependencies.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">At that point, organizations typically introduce a Scrum of Scrums of Scrums (SoSoS), SAFe ART Sync, or another scaling coordination mechanism.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>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&#8230;<\/p>\n","protected":false},"author":4,"featured_media":8263,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","footnotes":""},"categories":[2],"tags":[],"class_list":["post-8262","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agile"],"_links":{"self":[{"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/posts\/8262","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/comments?post=8262"}],"version-history":[{"count":1,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/posts\/8262\/revisions"}],"predecessor-version":[{"id":8265,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/posts\/8262\/revisions\/8265"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/media\/8263"}],"wp:attachment":[{"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/media?parent=8262"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/categories?post=8262"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/tags?post=8262"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}