Scrum of scrums is the lightweight, stand-up-style meeting that lets many agile teams move together as if they were one. When only a single squad is building a product, a 15-minute Daily Scrum keeps everyone aligned. But scale that to ten, twenty, or even fifty teams sharing the same release date, and you risk drowning in status calls and hidden blockers. In the Scaled Agile Framework (SAFe), the scrum of scrums solves this problem by bringing one delegate from each team into a fast, focused sync. They share cross-team progress, surface dependencies, and clear impediments before they slow the train. In the rest of the post we’ll unpack how the scrum of scrums works, why SAFe puts it at the center of large programs, and practical tips to run it well.
Why do we need the scrum of scrums
Running many teams like they are one big team does not scale. A normal Daily Scrum becomes a two-hour roll-call, and nobody hears the important parts. As a result:
- Cross-team dependencies stay hidden until late.
- Teams duplicate effort or step on each other’s code.
- Blocking issues bounce from team to team with no owner.
A scrum of scrums solves these pains by adding a lightweight second stand-up. Each team sends one delegate. The delegate shares only the news that other teams need, not every detail. In this way we keep the energy of Scrum but spread it across the whole “train” of teams.
How SAFe® places the scrum of scrums
SAFe organizes work around an Agile Release Train (ART). An ART is usually 5–12 Scrum teams that plan, build, and release together. SAFe offers two main sync ceremonies:
| SAFe Sync | Primary focus | Typical attendees |
|---|---|---|
| PO Sync | Backlog, priorities, customer value | Product Owners, Product Manager |
| Scrum of Scrums (SoS) | Execution, dependencies, impediments | Scrum Masters or rotating team reps |
Together, these two meetings form the ART Sync. The PO Sync looks forward at what to build next, while the scrum of scrums looks sideways at how all teams move today.
The “scrum of scrums” meeting in detail
1. Who joins?
- One representative per team – often the Scrum Master, but SAFe encourages a rotating engineer so knowledge spreads.
- Release Train Engineer (RTE) – the chief Scrum Master who facilitates.
- Optional system architect, DevOps lead, or product leadership – only when needed for decisions.
2. How often?
Most ARTs run the scrum of scrums two or three times a week. Some high-risk phases (for example right before a system demo) call for daily syncs. Keep it regular and time-boxed so people trust it.
3. How long?
15–30 minutes. If you hit 30 often, look for side topics to spin out.
4. What questions?
A classic pattern is an expanded “three questions”:
- What did my team finish since the last SoS that others should know?
- What will my team work on next that touches another team?
- Where are we blocked, or where might we block someone else?
Some groups add a fourth: “Do we have new risks or learnings from customers?” Use whatever prompts expose dependencies fastest.
Roles and responsibilities inside the scrum of scrums
Release Train Engineer (RTE)
- Schedules and facilitates the SoS.
- Makes sure impediments land on the right owner.
- Escalates to managers or Lean Portfolio Management if stuck.
Team Representatives
- Carry their team’s voice to the scrum of scrums.
- Bring back decisions and warnings.
- Have the authority to commit to minor adjustments (for example, swapping story order).
Architect-Engineer
- Clarifies technical dependencies.
- Flag design drift that could hurt the overall solution.
Leadership sponsors
- Join only when the train faces a program-level roadblock (budget, vendor, policy).
- Empower rapid decisions so teams keep flow.
Setting up your first scrum of scrums
- Pick a clear cadence – e.g., Monday, Wednesday, Friday at 10 a.m. right after teams finish Daily Scrums.
- Create a shared board or chat channel – list teams across the top and SoS dates down the side. Each delegate posts bullet points before the meeting; callouts turn yellow or red if urgent.
- Define “ready” criteria – delegates must know the status of cross-team work before joining. No reading Jira on the call!
- Rotate delegates every PI or even every sprint so engineers, testers, and designers gain system vision.
A walk-through example
Picture eight Scrum teams building an online banking app inside a single ART.
| Team | Current goal | Key dependency |
|---|---|---|
| Payments | Integrate new card gateway | Needs API from Security |
| Security | Deliver token v2 API | Waiting on legal approval |
| Mobile | Show real-time card status | Needs Payments service |
| Accounts | Migrate account history | Needs DBA window |
In Monday’s scrum of scrums:
- Security delegate says the legal review slipped a week.
- Payments sees immediate impact and agrees to create a stub service so Mobile can test while waiting.
- RTE records an action: “Legal review escalate by Tuesday.”
- DBA capacity risk is noted; Accounts and Payments plan a joint database migration test.
By Wednesday, legal has approved. Payments removes the stub. Mobile keeps momentum, and no team idles. That is the scrum of scrums delivering value: early warning, joint problem-solving, fast decisions.
Related SAFe articles
Common mistakes in a scrum of scrums
1. Turning into a giant status report
If each delegate reads every story or ticket, you will bore the group and hide real issues. Focus on what affects other teams.
2. Letting only Scrum Masters speak
Rotating engineers brings technical depth. It also teaches every member to think beyond their local sprint.
3. Skipping notes or action owners
A scrum of scrums without visible follow-up feels pointless. Track actions in the shared board and review at the next meeting.
4. Inviting everyone “just in case”
The power of SoS is the small room that can make decisions quickly. Observers may lurk on a muted call stream but should not fill the meeting.
Benefits you will feel
| Benefit | Why it matters |
|---|---|
| Fast visibility of blockers | Issues surface within a day or two instead of end-of-sprint surprises. |
| Real-time dependency planning | Teams adjust sequence on the fly, reducing idle hands. |
| Shared ownership of the whole solution | Delegates learn the big picture and spread it back to their squads. |
| Reduced management escalation | Small problems solved here never grow into executive escalations. |
Metrics like flow time, failed deployments, and rework often improve after a healthy scrum of scrums practice takes root.
Tips for making your scrum of scrums shine
- Use visual flow metrics: a simple chart of stories “blocked by other teams” helps spot chronic patterns.
- Time-box strictly: set a visible timer. Spin-off deep dives with only affected parties.
- Celebrate cross-team wins: when Payments stub saved Mobile, call it out. Positive stories reinforce the habit.
- Align with PI objectives: remind everyone which Program Increment goal each risk threatens. Connections spark urgency.
- Keep technology light: a shared Miro board or even a sticky-note wall works better than a complex plugin nobody updates.
Frequently asked questions about the scrum of scrums
Is the scrum of scrums mandatory in SAFe?
Strictly speaking, no ceremony is forced. But most ARTs find it essential once you pass four or five teams.
Can Kanban teams join?
Yes. The delegate simply summarizes Kanban flow (e.g., “We pulled two features to doing; need code review support tomorrow”).
How is the scrum of scrums different from Program Increment (PI) Planning?
- PI Planning sets goals for the next 8–12 weeks.
- Scrum of scrums checks progress against those goals twice a week.
Think of PI Planning as the map, and the scrum of scrums as the GPS updating your route.
Do we need special tools?
Start with a spreadsheet or whiteboard. Add tools only when you feel pain.
Conclusion: small meeting, big coordination
The scrum of scrums proves that scaling agile does not mean adding heavy process. By keeping the stand-up spirit but narrowing the attendee list, SAFe’s scrum of scrums gives large groups the same adaptability that makes a single Scrum team shine. Run it well, and you will see fewer blockers, clearer ownership, and, most of all, happier teams that trust that someone is steering the big ship.
Begin with a simple schedule, a shared action board, and a culture of honesty. Rotate delegates, track actions, and celebrate small wins. Soon your Agile Release Train will move as one—without the noise of endless status meetings. That is the quiet power of the scrum of scrums.