Scrum@Scale

Scrum@Scale on one screen

Here is the whole framework first. The Scrum@Scale Guide defines it as twelve components: two hubs, three components on the Scrum MasterScrum Masterremoves what blocks the teamThe person responsible for the process working, not for the work getting done. They remove blockers and protect the team from interruption — they are not the manager of the team, and treating the role as management is the usual way it fails.Full article →All terms cycle, four on the Product OwnerProduct Ownerowns what gets builtThe one person accountable for what the team builds and in what order. The authority is real — a Product Owner who has to get every decision approved elsewhere is a messenger, and the role stops working.Full article →All terms cycle, and three where the two cycles meet. If you are diagnosing an organisation rather than learning the framework, read the last column first — it is what each component looks like when nobody carries it.

The tables follow the current Guide, version 2.1 of February 2022, released under CC BY-SA 4.0. The first edition, of February 2018, called the Delivery component Deployment and used "MetaScrum" for the group of Product Owners that 2.1 calls the Product Owner Team; much of what circulates about the framework still uses those names.

One pattern at every size

The Guide defines Scrum@Scale as a lightweight organisational framework in which a network of teams, each working consistently with the Scrum Guide, can address complex adaptive problems. Two ideas carry the rest. The first comes straight from Scrum: accountability for what gets built is kept apart from accountability for how it gets built. Scrum does that with two roles, Product Owner and Scrum Master. Scrum@Scale does it with two cycles, each with its own people and its own hub, meeting only at named components.

Keeping them apart is the design point, not an accident of the diagram. In most organisations the how side quietly takes over the what side: whoever controls capacity ends up deciding priorities, because every priority can be argued as a capacity question. The Guide’s stated reason for the split is to make jurisdiction explicit, so that this conflict — which it calls wasteful — never starts.

The second idea is what the Guide calls a minimum viable bureaucracy: the fewest governing bodies and processes an organisation needs to function without slowing the delivery of value. Its mechanism is a scale-free architecture — a lesson the Guide credits to Intel: nothing scales except a scale-free architecture. In practice it means a group of teams works exactly like a team. Four or five Scrum teams form a Scrum of Scrums, with its own Scrum Master, its own Product Owner, its own daily event and its own retrospective. Four or five of those form a Scrum of Scrum of Scrums, with the same again. Nothing new is invented at each level.

Four or five is not arbitrary, and the Guide says where it comes from. The Scrum Guide puts a team at ten people or fewer; the Guide cites Harvard research putting the optimal team at 4.6 people on average, and applies the same number one level up. It is worth noticing what that argument does and does not show. The 4.6 figure is about people working together all day; the Guide transfers it to teams in a group of teams, whose members are representatives meeting for fifteen minutes. The transfer is plausible. It is not measured.

The arithmetic behind the nesting is simpler, and it does hold. Twenty-five teams that all coordinate with one another have 300 possible pairs. Five groups of five have 10 pairs inside each group, 50 in all, and their five representatives have 10 more between them: 60. The Guide’s own phrase is that scaling the Scrum of Scrums reduces the number of communication pathways. The price is distance. A problem between two teams in different groups now takes three hops instead of one — from the team to its group’s representative, across to the other group’s representative, and down to the other team — which is why the scaled daily events run in sequence each morning rather than once a week.

The Guide names the goal of all this linear scalability, which it defines as a corresponding percentage increase in delivered working product with an increase in the number of teams: double the teams, double the output. Most organisations get the opposite — each team added contributes less than the one before — and the Guide’s closing note promises more still, an organisation delivering twice the value at half the cost. Read both as the design target they are. The Guide offers no data behind either, and the independent studies at the end of this page do not measure them.

The Scrum Master cycle: coordinating the how

Three components sit on this cycle, and the Scrum Master organisation carries them: the teams’ Scrum Masters, the Scrum of Scrums Masters and, at the hub, the Executive Action Team. Naming the components separately is what lets you say "our problem is Delivery" instead of "we should do more agile".

• Continuous Improvement and Impediment Removal

  Find impediments and treat each as a chance to improve; keep them visible; keep an environment in which they are ordered and removed; and check that each improvement actually moved a team or product metric. The last goal is the one most often skipped, and it is what separates improvement from activity.

• Cross-Team Coordination

  Bring similar processes in related teams into line, deal with dependencies between teams before they turn into impediments, and keep team norms aligned so the output is consistent. The Scaled Daily ScrumDaily Scrumthe team’s 15-minute re-planA fifteen-minute event, every working day, where the Developers inspect progress toward the Sprint Goal and re-plan the next twenty-four hours. It is not a status report: if it only works with a manager in the room, it has already become one.Full article →All terms exists for this component.

• Delivery

  A steady flow of valuable, finished product to customers, the work of different teams integrated into one seamless product, and a high-quality experience for the people using it. The 2018 edition called this component Deployment.

The Scrum of Scrums and its Master

A Scrum of Scrums operates as if it were a Scrum team. It is responsible for a fully integrated set of potentially shippable increments at the end of every SprintSprinta fixed-length work cycleA fixed period, usually one to four weeks, at the end of which there is something finished enough to show. The length is fixed and the scope moves — a sprint that is extended to fit the work has given up the only thing it was for.Full article →All terms — one product, not five team outputs. Its Scrum of Scrums Master is accountable for the scaled events taking place, being productive and staying inside their timebox, and, with the Chief Product Owner, for a releasable increment at least every Sprint. The Guide gives them three more duties: make impediments, improvements and progress visible to the organisation; coordinate the teams’ delivery with the release plan; and lead the ordering and removal of impediments, with particular attention to the ones between teams.

The pattern is older than the framework. Sutherland first ran a Scrum of Scrums at IDX Systems in 1996, to keep the teams of eight business units in step, and described it in 2001. What Scrum@Scale, first presented in 2014 and written down in the 2018 Guide, made a rule is that the group is a team — with roles, events and a backlog of its own, and accountability for one integrated result — rather than a meeting of team leads.

The Scaled Daily Scrum

At least one representative from each team attends, and anyone else from the teams may come as needed. It mirrors the Daily Scrum: fifteen minutes or less, every team represented, and a conversation about how the teams can work together better — what has been done, what will be done, what is going wrong and why, and what the group will do about it. The Guide frames it with three questions, and the second column is what separates an answer from a status report.

Most organisations hold it straight after the team dailies, which turns a blocker one team cannot remove into a problem the group owns before lunch. What it must not become is a round of progress reports: if every representative describes their team’s work and nobody names a blocker, the event is being used to report upward, and the representatives are usually the wrong people.

The Scaled Retrospective

Every Sprint the Scrum Masters of the teams meet to discuss which experiments their teams ran to improve, and what came of them. It is where an improvement found in one team becomes available to the other four, and where an impediment that keeps appearing across teams is recognised as the group’s rather than any one team’s — and, if the group cannot remove it either, sent up the cycle.

The Executive Action Team

The hub of this cycle fulfils the Scrum Master accountabilities for the whole agile organisation. It is accountable for removing the impediments that the Scrum of Scrums, or the wider network, cannot — and so, the Guide says, it must be made of people who are empowered, politically and financially, to remove them. It is not a steering committee. As with any Scrum team, it needs a Product Owner, a Scrum Master and a transparent backlog, and that backlog holds the initiatives of the organisation’s own transformation.

Its work, as the Guide lists it, is mostly about the organisation rather than the product: an agile operating system for the Reference Model as it spreads — the company rules, procedures and guidelines that let agile teams work — a Product Owner organisation that is created, funded and supported, the quality of Scrum measured and improved, capability built, and a translation layer between the agile network and every part of the company that is not agile. In practice, procurement, finance, HR and legal are where much of its backlog comes from.

The clearest published picture of this cycle working at size is Saab’s. In its May–June 2018 issue, Harvard Business Review described Saab’s aeronautics business — more than 100 agile teams across software, hardware and fuselage, building the Gripen fighter — coordinating through a ladder of stand-ups every morning. At 7:30 each team holds a fifteen-minute meeting and flags its impediments. At 7:45 the ones that need coordination go to a team of teams, which settles them or escalates them further. By 8:45 the executive action team has the list of critical issues it must resolve. The teams also share a rhythm of three-week Sprints.

Two cautions come with the case. The article was co-written by Jeff Sutherland, who created Scrum@Scale, so it is not independent evidence. And the result it cites — IHS Jane’s calling the Gripen the world’s most cost-effective military aircraft — is a property of the aircraft that the ladder may have helped deliver, not a measure of the ladder. What the case does show well is the mechanism: seventy-five minutes from a team’s blocker to the desk of someone who can remove it.

The Product Owner cycle: coordinating the what

Four components sit on this cycle, and the Product Owner organisation carries them: the teams’ Product Owners, the Chief Product Owners and the Executive MetaScrum. Together they answer one question — how a single direction survives contact with twenty-five teams without a project management office deciding it for them.

The Product Owner Team and the Chief Product Owner

Each Scrum of Scrums has one shared backlog feeding its teams, and a Product Owner Team to keep it: every team’s Product Owner, led by a Chief Product Owner who is accountable as the Product Owner for the group. The Chief Product Owner sets the strategic vision for the whole product, keeps one ordered backlog for all the teams, decides which metrics the team watches, adjusts the backlog on customer feedback and facilitates the MetaScrum. Each team’s Product Owner still decides what goes into their own team’s Sprint.

The Product Owner Team’s job is to make those individual decisions follow one path. The Guide lists what that takes: make the vision visible to everyone, build support among key stakeholders, keep one ordered backlog with no duplicated work, eliminate the dependencies the teams raise, produce a coordinated roadmap and release plan, and agree with the Scrum of Scrums Master a minimally uniform Definition of DoneDefinition of Donewhat "finished" means hereThe checklist a piece of work must pass before anyone may call it done — tested, reviewed, documented, deployed, whatever the team agreed. Its value is that "done" stops being a matter of opinion in a status meeting.Full article →All terms that applies to every team — the floor below which no team’s work counts as finished.

The Executive MetaScrum

At the hub, the Chief Product Owners meet executives and key stakeholders at an event the Guide calls the Executive MetaScrum. It is the forum for leaders and stakeholders to state their preferences to the Product Owner Team, negotiate priorities, change budgets or move teams — and the Guide adds the sentence that makes it work: at no other time during the Sprint should these decisions be made. It happens as often as needed and at least once per Sprint; the Chief Product Owner facilitates, and every team’s Product Owner, or a proxy, must attend. In a large implementation there may be several MetaScrums below it, whose strategic backlogs are set at the Executive MetaScrum.

That rule is older than the framework. At PatientKeeper, a Boston healthcare software company where Sutherland was chief technology officer, a weekly MetaScrum ran from 2003: an hour and a half, led by the lead Product Owner, with the CEO, senior management and the heads of marketing, development, QA, installation and support. Every release was reviewed there; Sprints were added, changed or dropped; sales staff had to make their case in the room for any change to a product rollout. Sutherland’s 2005 paper says company decisions affecting the backlog were made only in that meeting, which removed most of the lobbying, and calls it a key reason for the company’s success; in 2004 PatientKeeper put more than 45 enterprise releases live. It is the author’s account of his own company, with nothing to compare it against.

The rule does not mean nothing may change mid-Sprint. A production outage is not a priority decision; it is handled the way any Scrum team handles it. If a decision really cannot wait, Scrum already has the valve: a Product Owner can cancel a Sprint whose goal has become obsolete. What the rule removes is the third case — the senior person who wants something different on a Wednesday — by giving them a fixed place and time where they will be heard, and where the trade-off is made in front of everyone it affects.

Where the two cycles meet

The Guide’s wording is exact: the two cycles intersect at two components and share a third. The framework is usually summarised as two touchpoints, and the one left out of that summary, Metrics and Transparency, is the one that keeps the other two honest.

Team Process — the first intersection

Team Process is Scrum as the Scrum Guide prescribes it. Because every Scrum team has a Product Owner and a Scrum Master, every team is where the two cycles first meet. The Guide gives it four goals: maximise the flow of completed work that meets the Definition of Done, increase the team’s performance over time, work in a way that is sustainable and enriching for the team, and speed up the customer feedback loop. Everything above depends on it. Scaling teams that cannot finish work in a Sprint does not produce a scaled organisation; it produces more unfinished work, faster.

Product and Release Feedback — the second intersection

When a release reaches users, two different things come back, and the Guide sends them to different places. Product feedback — what customers do with the product, which assumptions held, which new needs appeared — goes to the Product Owner organisation and changes the backlog. Release feedback — how the delivery itself went — goes to the Scrum Master organisation and changes the delivery mechanism.

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

Metrics and Transparency — shared

Scrum@Scale does not prescribe a metric set, but the Guide says that at a bare minimum an organisation should measure four things, and gives an example of each.

The Guide’s reason for the component is decision latency: the numbers exist so that the Executive MetaScrum and the Executive Action Team decide on evidence and decide sooner. Read the four as a set. Each one alone can be improved by damaging another — productivity by cutting quality, quality by slowing delivery, both by burning the team out — and only the four together make that visible.

Adopting it: modular, not optional

The claim most often repeated about Scrum@Scale is that you adopt the components you need and leave the rest alone. The Guide says something narrower. Because the framework is made of components, it lets an organisation customise its transformation: target the areas most valuable or most in need of change first, and then progress on to the others. And in the next breath: changing the components’ core design, omitting them, or not following the base rules limits the benefits. The order is yours. The set is not.

Where to start is in the Guide too: develop a scalable Reference Model before scaling. It is a small set of teams that coordinate to deliver every Sprint — in practice, one Scrum of Scrums of four or five teams. As those teams succeed, the rest of the organisation has a working, healthy example to copy, and the Executive Action Team learns, at small scale, which company rules get in the way. Copying a Reference Model that does not yet deliver every Sprint copies its problems.

After that, the order is a diagnosis. The table maps the symptom a leadership team usually reports to the component to stand up first.

Scrum@Scale against Nexus, LeSS and SAFe

The four overlap most between three and nine teams, so size does not choose between them; what an organisation is willing to change does. Nexus changes no structure: it gives integration an owner in the Nexus Integration TeamNexus Integration Teamthe one role Nexus adds to ScrumThe accountability Nexus adds to Scrum: the Product Owner, a Scrum Master and members drawn from the Scrum teams, answerable for a done, integrated increment at least once every Sprint. It coaches the teams to integrate their own work; one that does everyone’s merges has become the hand-off Nexus exists to remove.Full article →All terms, and it is the lightest answer when integration is the one thing that broke. LeSS asks for the reorganisation that makes most dependencies disappear — every team a feature teamfeature teama team that owns features end to endA long-lived, cross-functional team that takes a customer-visible piece of the product from idea to done, working in every component it touches. The alternative is component teams, one per technical layer, where one feature waits in several teams’ queues; the price of feature teams is learning to work in code the team did not write.Full article →All terms, able to take a customer-visible feature from idea to done — and pays back more when leadership will do it. SAFeSAFeScaled Agile Framework — a framework for running many agile teams as oneThe Scaled Agile Framework: roles, events and practices for coordinating dozens of agile teams, built around the Agile Release Train — five to twelve teams that plan together every eight to twelve weeks. It is the most prescriptive and the most widely adopted scaling framework, which is also why it can be installed without changing who makes the decisions.Full article →All terms starts from the existing structure and adds a layer above the teams, the Agile Release TrainAgile Release Train5–12 teams that plan and deliver togetherIn SAFe, a long-lived group of five to twelve agile teams, usually 50 to 125 people, that plan together at PI Planning, work to the same iteration boundaries and integrate their work every iteration. It should be drawn around the path a product takes to its customers; a train drawn around the existing departments coordinates them without changing anything.Full article →All terms, which coordinates them on a shared Planning Interval of eight to twelve weeks.

Scrum@Scale sits between them in weight and apart from them in one respect. It keeps the Sprint as the planning horizon at every level, as Nexus and LeSS do and SAFe does not. It leaves team structure to the organisation, which LeSS does not. And it is the only one of the four that writes the executives into the framework as Scrum teams with their own backlogs, and says when they may change priorities. That is its strongest idea and its most common point of failure: the part a framework assigns to leadership is the part leadership is most likely to postpone.

One detail shows how the vocabulary travels. SAFe had an event called the Scrum of Scrums on every train until version 6.0 renamed it Coach Sync in 2023. In Scrum@Scale the Scrum of Scrums is a team, with a backlog and accountability for one integrated product; in SAFe before 6.0, and in most organisations that use the name, it is a meeting. That difference is most of the difference between the framework and its imitation.

What the evidence shows

Read together, the record is thin in the same way as Nexus’s, for a different reason. The detailed accounts come from the framework’s creator; the large surveys count the Scrum of Scrums, which is the part of Scrum@Scale most organisations already had. Verwijs and Russo’s finding is still worth keeping: the simplest approaches — the Scrum of Scrums and LeSS — scored slightly higher on management support than the rest, 5.11 and 5.07 against 4.57 to 4.88, by margins the authors call too small to matter in practice. None of these sources isolates the two components that make Scrum@Scale different, the Executive MetaScrum and the Executive Action Team. Whether they deliver what the Guide promises is, today, an argument rather than a finding.

Where it degrades

Scrum@Scale fails in a recognisable way, and its own structure predicts it. The components that cost the teams something get adopted; the components that cost leadership something get postponed. A Scrum of Scrums is easy to start — it is a meeting. An Executive MetaScrum means executives agreeing to change priorities once per Sprint, in public, and not in between. An Executive Action Team means executives taking on a backlog of their own organisation’s impediments and being asked each Sprint which ones they removed.

That is the honest limit. The framework describes exactly what leadership should do and gives nobody below leadership the means to make it happen. A framework that places its most important components at the top of an organisation gets adopted from the bottom, and stops where the authority to adopt it stops. What remains is a Scrum of Scrums — useful, well documented, and not what the Guide is about.

• A Scrum of Scrums run as a status meeting, with no backlog of its own and no impediment ever removed.
• A Scaled Daily Scrum attended by managers reporting progress rather than by team members raising blockers.
• No Executive Action Team, so organisational impediments are raised forever and removed never.
• An Executive Action Team of delegates without budget authority, which can name impediments but not remove them.
• No Executive MetaScrum, so priorities change whenever someone senior is unhappy.
• An Executive MetaScrum that meets on schedule while priorities still change in corridors between meetings.
• The two hubs merged into one leadership forum, after which the how side starts deciding the what.
• Groups far larger than five teams, where the coordination event stops being a conversation.
• Scaling before the Reference Model delivers every Sprint, which copies its problems into every new group.
• Components treated as a menu, with the uncomfortable ones still "not needed yet" two years in.

When to use it

Related pages

• ManagementSAFeSAFe, the Scaled Agile Framework, is a set of roles, events and practices for running dozens of agile teams on one 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. The page opens with the whole framework on one screen — every event at every level with its cadence, and who sits at each level — then covers the Agile Release Train and the Planning Interval, the four configurations and the adoption roadmap, PI Planning and Inspect & Adapt, how SAFe measures itself and how each measure is gamed, its values and ten principles, what the independent evidence shows, and where it degrades.
• ManagementNexusNexus is Scrum.org’s framework for three to nine Scrum teams building one product, and it adds exactly one accountability to Scrum: a Nexus Integration Team. Its premise is that at this scale integration, not planning, is what breaks first. The page opens with every Nexus element on one screen — each event and what it does to its Scrum counterpart, and the three artefacts with their commitments — then covers why the one addition, who is really on the Integration Team, each event as the 2021 Guide defines it and what changed from 2018, how to find and remove dependencies, how Nexus compares with LeSS, SAFe and Scrum@Scale, what the evidence shows and where it degrades.
• ManagementLeSSLeSS (Large-Scale Scrum) is a framework that scales Scrum by running many teams as one: one Product Owner, one Product Backlog, one Sprint, one product. It scales by removing organisational structure rather than adding it, which makes it the most demanding framework to adopt and the closest to Scrum itself. The page opens with every rule and every event on one screen, then covers descaling and the product definition, feature teams and what LeSS removes, the ten principles, each event, LeSS Huge and its Requirement Areas, what four dated adoptions show, and where it degrades.