Nexus Framework: Scrum für 3 bis 9 Teams skalieren

Von Tara Minh · Aktualisiert am 10. Oktober 2026

Nexus ist ein Framework von Scrum.org für etwa drei bis neun Scrum-Teams, die gemeinsam an einem Produkt arbeiten. Es behält die Regeln von Scrum bei und ergänzt nur, was zur Steuerung von Abhängigkeiten nötig ist: ein Nexus Integration Team, einige zusätzliche Events und ein gemeinsames Integrated Increment, zu dem jedes Team in jedem Sprint beiträgt.

Der meiste Schmerz beim Skalieren hat nichts mit schnellerem Programmieren zu tun. Es geht darum, dass zwei Teams dasselbe Modul anfassen, ein drittes auf beide wartet und es niemand bemerkt, bis der Sprint fast vorbei ist. Nexus ist um genau dieses Problem herum gebaut. Es verlangt nicht, das Unternehmen umzubauen. Es verlangt, Abhängigkeiten früh sichtbar zu machen und jemandem klar die Verantwortung für die Integration zu geben.

Wichtige Fakten

• Nexus wurde von Ken Schwaber und Scrum.org entwickelt, und der Nexus Guide erschien in Ausgaben von 2015, 2018 und 2021.
• Der aktuelle Nexus Guide (Januar 2021) beschreibt einen Nexus als etwa drei bis neun Scrum-Teams mit einem Product Owner und einem Product Backlog.
• Das Nexus Integration Team besteht aus dem Product Owner, einem Scrum Master und einem oder mehreren Nexus Integration Team Members.
• Der Guide nennt keine festen Timeboxes für die Nexus-Events. Ihre Dauer orientiert sich an den entsprechenden Scrum-Events.
• Die Ausgabe von 2021 benannte Refinement in Cross-Team Refinement um.
• LeSS deckt 2 bis 8 Teams ab, die beiden Frameworks überschneiden sich also stark bei der Teamanzahl und unterscheiden sich vor allem darin, wie viel organisatorische Veränderung sie verlangen.

Was ist das Nexus Framework?

Nexus ist ein Framework zur Entwicklung und Aufrechterhaltung skalierter Produktlieferung. Es erweitert Scrum minimal. Teams führen weiterhin Sprints durch, haben einen einzigen Product Owner und ein einziges Product Backlog und folgen denselben Scrum-Werten. Neu ist, dass die Gruppe ein Integrated Increment statt mehrerer lose verwandter erzeugt und eine kleine Gruppe die Verantwortung dafür übernimmt, dass diese Integration gelingt.

Das Wort "Nexus" bedeutet Verbindungspunkt, und das Framework dreht sich größtenteils um Verbindungen: zwischen Backlog-Items, zwischen Teams und zwischen dem, was jedes Team als Done bezeichnet, und dem, was tatsächlich gemeinsam ausgeliefert wird.

Drei Ideen tragen das meiste Gewicht:

• Ein Produkt, ein Backlog. Alle Teams ziehen aus demselben Product Backlog, das ein Product Owner verantwortet.
• Abhängigkeiten sind der Feind des Flusses. Verfeinern Sie sie vor dem Sprint weg und verfolgen Sie die verbleibenden.
• Integration findet in jedem Sprint statt. Der Nexus muss mindestens einmal pro Sprint ein funktionierendes, integriertes Increment erzeugen, nicht erst am Ende einer Release-Phase.

Nexus-Rollen: das Nexus Integration Team

Nexus fügt keine neue Managementebene hinzu. Es fügt ein Team hinzu. Laut Nexus Guide gehören zum Nexus Integration Team:

Das häufigste Missverständnis lautet, das Integration Team übernehme die Integration. Das tut es nicht. Jedes Scrum-Team leistet weiterhin seine eigene Integrationsarbeit. Das Integration Team koordiniert, coacht und räumt Hindernisse aus dem Weg, und es verantwortet, dass das Integrated Increment tatsächlich existiert und die Definition of Done erfüllt. Es besitzt außerdem die gemeinsame Definition of Done für das Integrated Increment. Einzelne Teams dürfen sich an einen strengeren Maßstab halten, aber an keinen lockereren.

Die Besetzung kann sich ändern, wenn sich die Arbeit ändert. Der Guide besagt, dass der Platz einer Person im Integration Team Vorrang vor ihrer Teammitgliedschaft hat, solange die Aufgaben des Integration Teams erfüllt werden, was höflich ausdrückt, dass die Rolle zuerst kommt, wenn beide kollidieren.

Nexus-Events

Nexus behält die Standard-Events von Scrum bei und umgibt sie mit teamübergreifenden Varianten. So funktioniert jedes davon laut Nexus Guide.

Ein paar praktische Hinweise dazu, wie sich das auswirkt:

Cross-Team Refinement ist das Event, das seinen Preis wert ist. Wenn Ihre Teams in der Sprint-Planung feststellen, dass Team B von Team A eine Schemaänderung braucht, ist die Verfeinerung gescheitert. Behandeln Sie sie als laufende Arbeit, eng verwandt mit dem normalen Backlog Refinement, aber mit der besonderen Aufgabe, teamübergreifende Abhängigkeiten zu erkennen und zu verkleinern.

Nexus Sprint Planning ist der Termin, an dem Vertreter der Teams die Reihenfolge der Arbeit und die Teamzuordnungen bestätigen, woraufhin jedes Team seine normale Sprint-Planung für seinen eigenen Ausschnitt durchführt. Das daraus entstehende Nexus Sprint Backlog ist die gemeinsame Sicht auf alles, was im Spiel ist.

Das Nexus Daily Scrum ist für Vertreter gedacht, nicht für alle. Es ist kurz, es geht um Integration, und sein Ergebnis sind Anpassungen am Nexus Sprint Backlog und an den eigenen Plänen der Teams.

Nexus-Artefakte

Nexus nutzt die Scrum-Artefakte und ergänzt einige gemeinsame Versionen:

Der Guide verwendete in früheren Ausgaben den Begriff "Nexus Goal" und benannte ihn 2018 in Nexus Sprint Goal um, passend zur Wortwahl von Scrum. Wenn Sie ältere Blogbeiträge lesen, erwarten Sie den älteren Begriff.

Nexus im Vergleich zu SAFe, LeSS, Scrum of Scrums und Disciplined Agile

Nexus liegt in der leichteren Hälfte des Skalierungsspektrums. So schneidet es im Vergleich zu den Optionen ab, die man üblicherweise dagegen abwägt.

Zwei Vergleiche verdienen je einen Satz. Gegenüber SAFe ist Nexus die kleinere Verpflichtung: Sie führen keine Planungstaktung für das gesamte Unternehmen ein, sondern ergänzen Teams, die bereits ein Produkt teilen, um ein Koordinationsteam. Gegenüber LeSS liegt der Unterschied darin, wie viel Sie bereit sind umzuorganisieren. LeSS verlangt Feature-Teams und einen einzigen Product Owner mit echter Befugnis über alles, während Nexus davon ausgeht, dass Sie diese Grundlagen bereits haben und Hilfe bei den Integrationsnähten brauchen.

Scrum of Scrums ist die leichteste Option von allen. Es ist ein wiederkehrendes Meeting, in dem Teamvertreter Abhängigkeiten teilen, und oft das, was Teams tun, bevor sie etwas Formelles einführen. Nexus lässt sich als strukturiertere Version dieser Idee lesen, mit definierten Events, Artefakten und einer verantwortlichen Gruppe dahinter.

So starten Sie mit Nexus

Hier eine Abfolge, die dazu passt, wie Teams es üblicherweise einführen.

1. Voraussetzungen bestätigen. Sie sollten drei oder mehr Teams haben, die ein Produkt bauen, einen Product Owner und Teams, die bereits eigenständig einen ordentlichen Sprint fahren können. Nexus repariert kein Team, das noch kein Scrum betreibt.
2. Das Nexus Integration Team bilden. Benennen Sie den Product Owner, wählen Sie einen Scrum Master und bestimmen Sie ein oder zwei erfahrene Personen aus den Teams als Integration Team Members. Halten Sie in einer kurzen Arbeitsvereinbarung fest, was Sie von ihnen erwarten.
3. Eine gemeinsame Definition of Done schreiben. Sie soll die Integration abdecken, nicht nur die Fertigstellung auf Teamebene, sodass "Done" bedeutet: funktioniert mit allem anderen.
4. Mit Cross-Team Refinement beginnen. Wählen Sie jede Woche einen festen Termin. Gehen Sie die Spitze des Backlogs durch, markieren Sie Abhängigkeiten und schneiden Sie Items, bis die meisten von einem Team abgeschlossen werden können.
5. Nexus Sprint Planning durchführen. Wählen Sie ein Nexus Sprint Goal, ordnen Sie Items den Teams zu und bauen Sie das Nexus Sprint Backlog mit sichtbaren verbleibenden Abhängigkeiten.
6. Ein Dependency Board führen. Nutzen Sie die Vorlage unten und besprechen Sie sie im Nexus Daily Scrum.
7. Ein einziges Nexus Sprint Review und eine Retrospektive abhalten. Zeigen Sie ein Integrated Increment statt fünf Demos und verbessern Sie, wie die Teams zusammenarbeiten.
8. Prüfen und anpassen. Wenn Integrationsprobleme immer wieder spät auftauchen, beheben Sie zuerst die Verfeinerung, dann die Teamzusammensetzung.

Vorlage: Dependency Board für teamübergreifende Abhängigkeiten

Kopieren Sie dies in Ihren Tracker und aktualisieren Sie es täglich. Es ist das Artefakt, nach dem Teams beim Start mit Nexus am häufigsten fragen.

Hinweise zu den Spalten:

• Benötigt von / Benötigt durch hält die Richtung der Abhängigkeit explizit fest. Ohne sie werden Boards zu Sorgenlisten.
• Benötigt bis sollte ein Sprint-Tag sein und kein vages "bald". Das wird im Nexus Daily Scrum besprochen.
• Status braucht nur vier Werte: Nicht begonnen, In Arbeit, Blockiert, Erledigt.
• Risiko bei Verspätung gibt dem Integration Team eine schnelle Rangfolge dafür, was zuerst verfolgt werden muss.

Eine gute Gewohnheit ist, die offenen Zeilen in der Nexus Sprint Planning und erneut nach dem Cross-Team Refinement zu zählen. Sinkt die Zahl von Sprint zu Sprint nicht, beseitigt die Verfeinerung keine Abhängigkeiten, und die Teamstruktur ist der nächste Verdächtige.

Beispiele nach Funktion

Nexus entstand in der Softwareentwicklung, aber die Mechanik gilt für jedes Produkt, das mehrere Teams in Sprints bauen.

Dos und Don'ts

Wann Nexus die falsche Wahl ist

Nexus passt nicht, wenn Sie weniger als drei Teams haben, denn dann genügt Scrum mit einer leichten Abstimmung. Es passt auch nicht, wenn Sie viele unabhängige Produkte statt eines einzigen koordinieren oder wenn Ihre Teams Scrum auf Einzelteam-Ebene noch nicht zum Laufen gebracht haben. Und wenn Sie Portfolio-Finanzierung, unternehmensweite Planung und umfangreiche Governance brauchen, deckt ein Framework wie SAFe mehr Gebiet ab. Nexus bringt Sie von drei Teams auf neun. Es gibt nicht vor, ein Betriebsmodell für ein ganzes Unternehmen zu sein.

Wenn Ihre Teams bereits Scrum betreiben und gegen Ende des Sprints immer wieder übereinander stolpern, ist Nexus eine kleine, risikoarme Veränderung: Benennen Sie ein Integration Team, beginnen Sie, nach Abhängigkeiten zu verfeinern, und prüfen Sie gemeinsam ein Integrated Increment. Beginnen Sie dort und fügen Sie nur dann Struktur hinzu, wenn das Board es Ihnen sagt.