Nexus-Events [Skalierung]

9 Übungsfragen mit Lösung und Erklärung.

✌️ MultiWelche Events ergänzt Nexus gegenüber Scrum? (Mehrere richtig)
Cross-Team Refinement.
Nexus Daily Scrum.
Nexus Sprint Zero zur Vorbereitung der Teams.
Nexus Sprint Retrospective.
Hinzu kommen außerdem Nexus Sprint Planning und Nexus Sprint Review. Ein Sprint Zero gibt es weder in Scrum noch in Nexus.
☝️ SingleWas ist der Zweck des Cross-Team Refinement?
Die Abnahme der Ergebnisse des letzten Sprints
Die Schätzung aller Einträge durch ein zentrales Gremium
Abhängigkeiten zwischen Teams frühzeitig sichtbar zu machen und Backlog-Einträge so zuzuschneiden, dass sie möglichst unabhängig umsetzbar sind
Die Zuweisung der Einträge an die einzelnen Teams durch den Product Owner
Das ist der wirksamste Hebel im gesamten Nexus: Eine früh erkannte Abhängigkeit lässt sich durch anderen Zuschnitt auflösen, eine spät erkannte muss koordiniert werden.
☝️ SingleWer nimmt am Nexus Daily Scrum teil?
Geeignete Vertreter der Developers aller Teams – es ersetzt die Daily Scrums der einzelnen Teams nicht
Ausschließlich die Scrum Master der beteiligten Teams
Alle Developers sämtlicher Teams gemeinsam
Der Product Owner und das Nexus Integration Team
Das Nexus Daily Scrum findet vor den Team-Dailys statt; seine Ergebnisse fließen dort ein. Thema sind ausschließlich Integrationsprobleme und Abhängigkeiten.
☝️ SingleWas ist das Nexus Sprint Backlog?
Eine Liste aller offenen Fehler über alle Teams hinweg
Die Aufgabenliste des Nexus Integration Teams
Das gemeinsame Backlog aller Teams, das das Product Backlog ersetzt
Eine Zusammenstellung der Einträge aus den Sprint Backlogs der Teams, die Abhängigkeiten und den Fortschritt zum Nexus Sprint Goal sichtbar macht
Es ersetzt die Sprint Backlogs der Teams nicht, sondern legt eine Sicht darüber – mit genau einem Zweck: Abhängigkeiten sichtbar halten.
☝️ SingleWie läuft das Nexus Sprint Review ab?
Es findet gemeinsam für den gesamten Nexus statt und inspiziert das integrierte Increment, statt getrennte Team-Reviews abzuhalten
Es ersetzt die Sprint Retrospective der einzelnen Teams
Es wird vom Nexus Integration Team ohne Stakeholder durchgeführt
Jedes Team führt sein eigenes Review durch und berichtet anschließend im Nexus
Getrennte Reviews würden Teilstände zeigen. Stakeholder interessiert aber das Produkt, nicht die Arbeitsteilung – deshalb wird das integrierte Ergebnis gemeinsam inspiziert.
☝️ SingleWie verhält sich die Nexus Sprint Retrospective zu den Retrospektiven der einzelnen Teams?
Sie dient dem Management zur Leistungsbewertung der Teams
Sie findet nur bei Bedarf statt
Sie rahmt diese ein: Zuerst werden nexusweite Themen identifiziert, dann folgen die Team-Retrospektiven, anschließend wird das Ergebnis zusammengeführt
Sie ersetzt die Team-Retrospektiven vollständig
Die Aufteilung folgt dem Einflussbereich: Was ein Team allein ändern kann, gehört in seine eigene Retrospektive; was nur gemeinsam entschieden werden kann, auf die Nexus-Ebene.
☝️ SingleWie läuft das Nexus Sprint Planning ab?
Der Product Owner weist den Teams ihre Einträge zu
Zuerst stimmen Vertreter aller Teams gemeinsam Reihenfolge und Abhängigkeiten ab und formulieren das Nexus Sprint Goal, danach planen die Teams einzeln weiter
Das Nexus Integration Team plant für alle Teams
Alle Teams planen gleichzeitig in einem gemeinsamen Raum ohne vorherige Abstimmung
Die Zweistufigkeit ist der Kern: gemeinsam nur so viel wie nötig, einzeln so viel wie möglich. Alles andere skaliert Meetingzeit statt Lieferfähigkeit.
☝️ SingleIn welcher Reihenfolge finden die Retrospektiven in einem Nexus statt?
Erst alle Team-Retrospektiven, danach eine gemeinsame ohne Rückkopplung
Erst die nexusweite Betrachtung gemeinsamer Themen, dann die Team-Retrospektiven, dann die Zusammenführung der Ergebnisse
Die Reihenfolge ist beliebig
Ausschließlich eine gemeinsame Retrospektive für alle Teams
Die Klammer sorgt dafür, dass übergreifende Themen in die Team-Retrospektiven hineinwirken und die dortigen Erkenntnisse anschließend wieder nach oben gelangen.
✍️ OffenEin Nexus hält alle Nexus-Events ab, liefert aber kein integriertes Increment. Analysieren Sie mögliche Ursachen.
Musterantwort: Die Events sind der Rahmen, nicht die Ursache der Integrationsfähigkeit – dass sie stattfinden, sagt über das Ergebnis wenig aus. Zu prüfen sind mehrere Ebenen. Erstens die Definition of Done: Haben die Teams tatsächlich eine gemeinsame und ausreichend strenge Fassung, oder arbeitet jedes Team mit eigenen Maßstäben? Unterschiedliche Fertigbegriffe machen ein gemeinsames Increment technisch unmöglich. Zweitens die technische Grundlage: Gibt es Continuous Integration über alle Teams hinweg, automatisierte Tests, die den Gesamtstand absichern, und gemeinsame Umgebungen? Fehlt das, bleibt Integration eine manuelle Kraftanstrengung, die unter Termindruck als Erstes ausfällt. Drittens der Teamzuschnitt: Komponenten-Teams erzeugen Abhängigkeiten systematisch, sodass am Sprint-Ende zwar alle Teile fertig sein können, aber keines für sich nutzbar ist. Viertens die Arbeitsweise im Cross-Team Refinement: Werden Abhängigkeiten dort tatsächlich aufgelöst, indem Einträge anders zugeschnitten werden, oder werden sie nur dokumentiert und anschließend verwaltet? Fünftens die Rolle des Nexus Integration Teams: Arbeitet es an den Ursachen, oder integriert es dauerhaft selbst und ist damit zum Engpass geworden? Der wirksamste erste Schritt ist meist, ehrlich zu beziffern, wie viel Arbeit am Sprint-Ende tatsächlich unintegriert bleibt, und diese Zahl sichtbar zu halten – sie erzeugt den Handlungsdruck, den Appelle nicht erzeugen.
← Alle ThemenIm Quiz üben