Scrum@Scale

Two cycles, repeated fractally

Scrum@Scale splits the work of running an organisation into two separate cycles. The Scrum Master cycle owns how work gets done — impediments, improvement, coordination between teams, getting things into production. The Product Owner cycle owns what gets done — vision, backlog order, decomposition, release decisions.

Keeping them separate is the design point, not an accident of the diagram. In most organisations the "how" side quietly takes over the "what" side: delivery managers end up deciding priorities because they control capacity. Two cycles with their own hubs, meeting only at defined points, is the structural answer to that.

The second idea is that the framework is scale-free. Four to five teams form a Scrum of Scrums, which behaves exactly like a Scrum team: it has its own daily, its own backlog of impediments and its own goal. Four to five of those form a Scrum of Scrum of Scrums. Nothing new is invented at each level — the same pattern repeats, which is why an organisation does not have to learn a different set of practices as it grows.

The five-team grouping is not arbitrary — it is the same span-of-communication constraint that caps a Scrum team at around nine people. Above that, the daily coordination meeting stops being a conversation and becomes a broadcast, and the people who no longer speak start solving their coordination problems in private channels instead.

The Scrum Master cycle: the "how"

Three components sit on this cycle. Each is a capability the organisation either has or does not — naming them separately is what lets you say "our problem is the third one" instead of "we should do more agile".

• Continuous improvement

  Identifying impediments and actually removing them — including the ones a team cannot remove itself. The measurable test is whether the same impediment appears in two consecutive retrospectives.

• Cross-team coordination

  Aligning the work of teams that share a goal, mostly by removing dependencies rather than by managing them. This is what the Scaled Daily Scrum exists for.

• Delivery

  Getting an integrated, releasable product into users' hands — the pipeline, the environments, the release mechanics. Earlier editions of the guide call this component Deployment.

The cycle's hub is the Executive Action Team, or EAT. It is a real Scrum team made up of leaders with the authority to change the organisation, and its backlog is the organisation's impediments. That authority requirement is the whole point: an impediment like "procurement takes six weeks to approve a test environment" cannot be removed by a Scrum Master, and if nobody with budget authority owns it, it is raised every sprint forever.

The role on this cycle is the Scrum of Scrums Master, or SoSM. They are accountable for the release of the joint work of their group of teams, the same way a Scrum Master is accountable for their team's process. The scaled events are the Scaled Daily Scrum — a short daily where representatives surface cross-team blockers, held after the team dailies — and a scaled retrospective where the group inspects itself as a unit.

The Product Owner cycle: the "what"

Four components sit on this cycle. Together they answer the question of how one direction survives contact with twenty teams without a project management office deciding it for them.

The cycle's hub is the Executive MetaScrum, or EMS — the forum where every competing stakeholder priority is reconciled into one ordered backlog by people with the authority to decide. It meets on a regular cadence, usually at least once per sprint, and it is run as an event called the MetaScrum. The role that leads this cycle is the Chief Product Owner, who owns the ordering of the whole product backlog the way a Product Owner owns one team's.

Where the two cycles touch

The cycles share exactly two components, and everything else runs independently. Those two shared points are where the "what" and the "how" have to agree, and limiting them to two is what stops one side absorbing the other.

It is worth being blunt about the second one. If releases are quarterly and feedback arrives as a report three weeks later, the Product Owner cycle is prioritising on opinion. Every other component can be in place and the organisation will still be guessing — which is why the delivery component on the Scrum Master side is usually the first thing to fix, even though it looks like a purely technical concern.

Scrum@Scale vs. SAFe

The practical trade-off is where the judgement has to come from. SAFe carries the judgement in the framework — the configuration tells you what to stand up. Scrum@Scale expects the organisation to supply it, which is cheaper and lighter when the diagnosis is right and produces a half-built set of meetings when it is wrong.

How this shows up in real delivery

Scrum@Scale's modularity is its strength and its risk. Adopted well, an organisation diagnoses that its bottleneck is prioritisation, stands up an Executive MetaScrum and fixes it without touching anything else. Adopted poorly, "modular" becomes permission to take the meetings and skip the accountability — a Scrum of Scrums that reports status upward and removes no impediments.

Where it degrades

• A Scrum of Scrums used as a status meeting rather than as a team with its own impediment backlog.
• No Executive Action Team, so organisation-level impediments are raised forever and never removed.
• Skipping the Executive MetaScrum, which leaves prioritisation to escalation.
• Groupings far larger than five teams, where the coordination meeting stops being a conversation.
• An Executive Action Team made of delegates without budget authority, which can name impediments but not remove them.
• The two cycles merged into one management forum, after which the "how" side starts deciding the "what".

When to use it

Related pages

• ManagementSAFeSAFe — the Scaled Agile Framework — coordinates dozens of teams by putting them on a shared planning rhythm. It is the most prescriptive of the scaling frameworks and by far the most adopted in large enterprises — precisely because it gives an existing management structure a defined place to stand. This page covers all four configurations, the roles above team level, the ten principles underneath it, and the honest case against it.
• ManagementNexusNexus is Scrum.org's scaling framework for three to nine teams working on one product. Nexus adds exactly one accountability to Scrum — an Integration Team responsible for a single integrated Increment — on the premise that at this scale integration, not planning, is what actually breaks. This page covers who is on that team, the three artefacts, and all five events.
• ManagementLeSSLeSS — Large-Scale Scrum — keeps one Product Owner, one Product Backlog, one Sprint and one shippable Increment, no matter how many teams. It scales by removing organisational structure rather than adding it, which makes it the most demanding scaling framework to adopt and the closest to actual Scrum. This page covers the ten principles, the rules-guides-experiments layering, every LeSS event, and both variants.