Nexus

Nexus on one screen

Here is the whole framework first. Nexus is small enough to fit in two tables, and the second column of the first one is the part to read: for each element, what Nexus does to the Scrum it already has. It adds, wraps, replaces or complements — and the difference between those four verbs is most of what there is to learn. Timeboxes follow the Scrum Guide’s for the matching event and come in addition to them.

The tables describe the current Nexus Guide, of January 2021. Much of what is written about Nexus, including course material and exam guides, follows the 2018 edition, which prescribed more; the differences are listed in the events section below.

One addition, deliberately

Nexus starts from a specific diagnosis. When three to nine Scrum teams work on one product, the first thing to break is usually not the coordination of plans — teams can generally talk to each other and divide work up. What breaks is the integration of the work. Code that was fine in isolation stops being fine when it meets the other eight teams’ code, and by the time anyone finds out, the 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 is over.

The Guide names two causes of the dependencies behind that. Product structure: how cleanly the product’s concerns are separated, which decides how many teams one change has to touch. And communication structure: how people talk within and between teams, where every delay slows the work. The numbers explain why it bites at this size. Nine teams of seven are 63 people, and 63 people have 1,953 possible pairs — the Estimation Methods page draws the same curve for smaller groups.

So Nexus adds one accountability and stops. Everything else stays as the Scrum Guide describes it: one 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, one Product BacklogBacklogthe ordered list of what is leftThe ordered list of everything that might be built, with the most valuable at the top. Ordered is the operative word: a backlog where everything is equally important is a wish list, and it makes no decision easier.Full article →All terms, one Product Goal, one Sprint of the same length for everyone. The word "Nexus" means a connection — between the teams, and between their work.

The Guide also makes a point most scaling material avoids: scaling the value delivered does not always mean adding people. More people and a bigger product mean more dependencies and more communication paths, and it calls reducing the number of people working on something — scaling down — an important practice in its own right. A Nexus that is struggling at nine teams may deliver more at six.

Who is really on the Integration Team

This is the part of Nexus most often misread, and the mistake is baked into the name. "Integration Team" sounds like a separate squad that merges everyone’s branches. It is not. The Nexus Integration Team is accountable for a done Integrated IncrementIncrementthe working result of a sprintEverything finished so far, taken together and actually working — not the pile of tickets closed this sprint. The test is whether it could be released today, even if the decision is not to.Full article →All terms being produced at least once every Sprint — accountable for it happening, not for doing it. The Scrum teams do the integrating.

• The Product Owner

  The same single Product Owner who owns the whole Product Backlog. Sitting on the Integration Team keeps ordering decisions connected to integration reality, instead of a backlog order that is technically impossible to deliver together.

• A Scrum Master

  Accountable for the Nexus framework being understood and enacted as the Guide describes. They may also be 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 of one or more of the teams, but the Nexus-level accountability is theirs alone.

• Integration Team Members

  People from the Scrum teams with the skills the current integration problems need — often build and deployment tooling, architecture, testing. Membership is not permanent and changes as the problems change.

The members keep working on their own teams, and that is the design: a person who spends part of the week on integration problems and the rest building the product carries the standard back into their team rather than guarding it from outside. The Guide describes the work as coaching, consulting and making dependencies and cross-team problems visible — teaching teams to produce work that integrates, not integrating on their behalf.

One rule settles the obvious conflict. Membership of the Integration Team takes precedence over membership of a Scrum team: when a problem affects several teams and your own team’s Sprint at the same time, the problem affecting several teams comes first. It is the one place Nexus overrides a team’s priorities, and it is written down so that nobody has to negotiate it in the moment.

Three artefacts, three commitments

Nexus keeps Scrum’s pairing of each artefact with a commitment and adds one artefact of its own. Each answers a different question, and the commitment attached to it is what stops the artefact drifting into a status report: the Product Goal for the backlog, the Nexus Sprint GoalSprint Goalwhy this sprint existsOne sentence, agreed at Sprint Planning, saying what will be different at the end of the sprint and why it is worth doing. It is what lets a team drop or swap individual items mid-sprint without failing — a sprint judged only by its list of tickets has a quota, not a goal.Full article →All terms for the Sprint’s combined work, the 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 for the Increment.

The Nexus Sprint Backlog deserves the most attention because it is the only genuinely new artefact. It is not a bigger to-do list; it is a dependency view. Teams look at it to see which of their items depend on another team’s item and when that item is expected — the information that separates finding a dependency on day two from finding it on day nine. The Guide asks for it to be detailed enough to inspect progress at every Nexus 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, and to be updated throughout the Sprint.

The Nexus Sprint Goal is one objective for the whole Nexus, made of the teams’ own Sprint Goals. Its job is coherence: nine teams each meeting their own goal while the product gains nothing usable is the outcome it exists to prevent.

The Definition of Done is where Nexus is strictest. There is one for the Nexus, the Integration Team is responsible for it, and every Scrum team must meet it. A team may apply a stricter one to its own work; it may never apply a looser one. Without that single standard, "integrated" means a different thing in each team, and the Integrated Increment is not integrated in any meaningful sense.

One sentence of the Guide is easy to miss and worth holding on to: the Integrated Increment is inspected at the Nexus Sprint Review, but it may be delivered to stakeholders before the Sprint ends. The Sprint is the latest moment the work must be integrated and done, not the only moment it may ship.

The events, one by one — and what changed in 2021

Each Scrum event gains a Nexus-level counterpart, and one new event runs throughout. None of them is a status meeting. Every one exists to surface a dependency or an integration problem earlier than it would otherwise appear. The diagram shows where each sits in a two-week Sprint and what it does to the team-level event beside it.

Cross-Team Refinement

This is the event that carries the most weight and gets skipped the most. Its job is to take Product Backlog items that are still too large and vague and break them down until one team could deliver each piece within a Sprint — and, in the same pass, to find the dependencies between the pieces, removing them where possible and making them visible where not. It has two outputs: a forecast of which team will take which item, and the dependency picture. It is ongoing, not a meeting in the calendar, and its frequency, length and attendance change with what the backlog needs. Refinement in Nexus is not an estimation ritual; it is dependency demolition done before the Sprint starts.

Nexus Sprint Planning

Representatives of each team meet with the Product Owner to plan the Sprint for the whole Nexus. The 2021 Guide defines it by what it produces rather than by steps: a Nexus Sprint Goal aligned with the Product Goal, a Sprint Goal for each team aligned with the Nexus one, the Nexus Sprint Backlog with its cross-team dependencies visible, and each team’s own Sprint Backlog. In practice the representatives agree the distribution, the teams plan in their own rooms, and the new dependencies they find go back onto the shared view before planning ends.

Nexus Daily Scrum

Representatives of the teams — usually developers close to the integration work, not managers — look at the current state of the Integrated Increment, find integration problems and newly discovered cross-team dependencies or impacts, and check progress toward the Nexus Sprint Goal. Each team’s own Daily Scrum then plans its day around what was raised, which is why the Nexus one comes first in the day. The Guide adds that this is not the only time teams may adjust their plans: teams talk across boundaries all day.

Nexus Sprint Review

The Nexus Sprint Review replaces the individual team reviews rather than adding to them. There is one review, of one Integrated Increment, with the key stakeholders, and the Product Backlog may be adjusted on the spot. The Guide accepts that not every piece of finished work can be shown in detail — nine separate demos of unintegrated parts would tell stakeholders nothing about whether the product works.

Nexus Sprint Retrospective

The Nexus inspects how the Sprint went across people, teams, interactions, processes, tools and its Definition of Done, and plans improvements for the whole Nexus. The teams’ own retrospectives complement it, bringing up from the bottom the problems that affect everyone. It concludes the Sprint.

That is all the 2021 Guide says, and here is what it no longer says. The 2018 edition prescribed a three-part retrospective: representatives meet to name shared problems, each team holds its own retrospective with those as input, and the representatives meet again to agree what will be done and how it will be tracked. It also named three questions every Nexus retrospective should ask: was work left undone, and did the Nexus create technical debt; was everything integrated often — as often as every day; and was the software built, tested and deployed often enough to stop unresolved dependencies piling up. None of that is a rule any more. All of it is still good practice, and the third part of the old retrospective is the one to keep if you keep nothing else — without it, shared problems get discussed every Sprint and fixed in none.

Finding dependencies before they find you

Every Nexus event is a chance to find a dependency, and the whole framework is a bet that finding one earlier is cheaper. That bet is easy to make concrete, because the cost of a dependency depends almost entirely on when it is discovered.

Once a dependency is found, there are three things to do with it, and they are not equal. Remove it: split the item differently, give the whole item to one team, or move a person for a Sprint so that one team holds every skill it needs. Sequence it: order the work so the providing team finishes first, early in the Sprint or a Sprint ahead. Or make it visible and manage it: put it on the Nexus Sprint Backlog with a date, and check it every day. The order matters. Most Nexuses default to the third, because it needs no decision, and end up managing the same kinds of dependency every Sprint.

Many Nexuses make the picture physical during Cross-Team Refinement: a board with a row per team and a column per upcoming Sprint, items as cards, and a string between two cards for every dependency. It is the same idea as 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’s planning board, run continuously over two or three Sprints ahead instead of once a quarter. A string that crosses the same two rows every Sprint is not a planning problem; it is the product or team structure the Guide names as the cause, asking to be changed.

Nexus against LeSS, SAFe and Scrum@Scale

The ranges overlap most between three and nine teams, so size alone does not decide. What decides is what the organisation is willing to change. Nexus changes no structure: it gives the integration problem an owner and a rhythm, and it is the right first move for most groups that have just outgrown one team. LeSS asks for the reorganisation that makes most dependencies disappear, and pays back more when leadership will do it. SAFe starts from the existing structure and adds the layers to coordinate it.

Past nine teams, Scrum.org’s answer is Nexus+: several Nexuses working on one product, integrated with each other the way a Nexus integrates teams. It is described in Scrum.org’s material and in the Nexus book by Bittner, Kong and West (2017), but no Guide defines it — a fair sign that this is the edge of the framework rather than its intended territory. The advice attached to it is the same as for Nexus itself: get very good at one Nexus first.

What the evidence shows

Independent evidence on Nexus is thin, and it is worth saying so. The one longitudinal study is Ersoy and colleagues’ at Paycell, a Turkcell company, published in the Journal of Software: Evolution and Process in 2024: twelve months of measurement in one product organisation, six under Scrum and six after switching to Nexus. It reports a significant rise in productivity and product quality after the switch, and a slight improvement in team motivation.

Read it for what it is: one organisation, before and after, with no comparison group, so the second six months also carry everything the teams learned in the first. The broader survey by Verwijs and Russo in 2024 — 15,078 team members in 4,013 teams — found only minor differences in team effectiveness between scaling approaches. Together they point the same way as the rest of this section: the framework is less decisive than whether the teams integrate their work continuously, which is the one thing Nexus asks for and cannot supply.

Where it degrades

Nexus only pays off if the Integrated Increment is real. That means a shared pipeline, a shared Definition of Done and integration at least daily. A Nexus without continuous integration is a set of meetings that discovers the same integration debt one Sprint later than it would have anyway — and it will be blamed on the framework rather than on the missing pipeline.

The honest limit is in the Guide’s own diagnosis. It names product structure and communication structure as the causes of dependencies, and Nexus gives nobody the authority to change either. It makes dependencies visible and gives integration an owner, which is real value — but a Nexus whose teams are cut so that every feature crosses three of them will find the same dependencies every Sprint, forever, and get very good at managing them. The Guide’s closing line cuts the other way too: implementing only parts of Nexus is possible, but the result is not Nexus.

• The Integration Team doing the merges instead of coaching teams to integrate their own work.
• A per-team Definition of Done, so "integrated" means different things in different teams.
• Skipping Cross-Team Refinement, which pushes dependency discovery into the Sprint.
• Every dependency managed on the board and none removed, so the same strings appear every Sprint.
• Nine separate Sprint Reviews instead of one review of the integrated product.
• Sending managers to the Nexus Daily Scrum, which turns a working session into a status round.
• A retrospective at Nexus level that names shared problems and assigns no one to fix them.
• Growing to twelve teams under one Product Owner without splitting the work or thinking about Nexus+.

When to use it

Related pages

• ManagementScrumScrum is a framework in which a team of ten or fewer ships a usable increment in fixed cycles of a month or less, called sprints, and adapts at five set events. It defines three accountabilities, three artefacts and those five events, and deliberately nothing about engineering. The page opens with the whole framework on one screen — every event with its timebox, who attends and what it produces — then covers the theory it rests on, each event in order along with the four meetings real teams add, the accountabilities and why the limit is ten, the Definition of Done and what happens when it stops short, five documented episodes, 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.
• ManagementScrum@ScaleScrum@Scale is Jeff Sutherland’s framework for scaling Scrum to a whole organisation: twelve components on two linked cycles, one for what gets built, one for how. Teams group four or five at a time into a Scrum of Scrums, the same pattern repeats at every level, and at the top two leadership groups run as Scrum teams. The page opens with all twelve components on one screen — what each is for, who carries it and what it looks like when nobody does — then covers the scaled roles and events, each cycle, where the cycles meet, how to adopt it in the order your problems demand, how it compares with Nexus, LeSS and SAFe, what the evidence shows and where it degrades.