Sprint [Events]

Musterantwort: Zürst wird die Lage transparent gemacht – im Daily Scrum, sobald die Erkenntnis vorliegt, nicht erst am Sprintende. Dann verhandeln die Developers mit dem Product Owner den Umfang neu: Das Sprint-Ziel bleibt bestehen, aber der konkrete Umfang der Arbeit ist im Sprint ausdrücklich verhandelbar. Möglich sind Aufteilung des Eintrags in einen kleineren, zielrelevanten Teil, Zurücknahme anderer Einträge oder eine reduzierte Lösung, die das Ziel dennoch erfüllt. Nicht scrum-konform wären: Verlängerung des Sprints, Absenken der Definition of Done, stilles Überziehen oder Nacharbeit außerhalb des Sprints. Lässt sich das Sprint-Ziel gar nicht mehr erreichen und ist es zudem obsolet geworden, kann allein der Product Owner den Sprint abbrechen. Die Ursache (Schätzung, Refinement-Tiefe) gehört in die Retrospektive.

Musterantwort: Die feste Sprint-Länge ist die Messlatte der Empirie. Würde man den Sprint verlängern, bis die geplante Arbeit fertig ist, verschwände genau die Information, um die es geht: nämlich dass mehr geplant wurde, als das Team leisten konnte. Der Vergleich zwischen Sprints wäre nicht mehr möglich, weil jeder Sprint eine andere Dauer hätte, und die Prognosefähigkeit ginge verloren. Zudem entfiele der regelmäßige Takt, auf den sich Stakeholder und Organisation verlassen. Stattdessen endet der Sprint zum festgelegten Termin. Was der Definition of Done entspricht, ist Teil des Increments; was nicht fertig ist, kehrt in das Product Backlog zurück und wird dort vom Product Owner neu bewertet und eingeordnet – es wandert also nicht automatisch in den nächsten Sprint. Im Sprint Review wird der tatsächliche Stand offen gezeigt, und die Retrospektive nimmt sich der Frage an, warum die Prognose nicht aufging. Wichtig ist die Unterscheidung: Die Sprint-Länge kann für künftige Sprints geändert werden, aber niemals während eines laufenden Sprints.

Musterantwort: Zunächst würde ich die Beobachtung von der Deutung trennen. Fünf verfehlte Ziele sind ein Muster, kein Einzelfall, und Muster haben meist systemische Ursachen. Auf Ebene des Sprint-Ziels: Ist es überhaupt ein Ziel oder nur eine Zusammenfassung der ausgewählten Einträge? Ein Ziel, das lautet "alle Einträge fertigstellen", ist konstruktionsbedingt nicht erreichbar, sobald etwas schiefgeht, weil es keinen Verhandlungsspielraum über den Umfang lässt. Auf Ebene der Planung: Wird der Umfang systematisch zu groß gewählt? Häufig steckt dahinter die Erwartung von außen, eine bestimmte Menge zuzusagen, oder die Unfähigkeit, Nein zu sagen. Zu prüfen ist auch, ob unsichtbare Arbeit anfällt, etwa Support oder Zuarbeit für andere Teams, die nie im Sprint Backlog auftaucht. Auf Ebene der Arbeit: Stauen sich Einträge am Ende des Sprints, weil alle parallel begonnen und nichts fertig wird? Werden Abhängigkeiten zu anderen Teams erst im Sprint sichtbar? Ist die Definition of Done so aufwendig, dass Fertigstellung strukturell nicht in einen Sprint passt? Auf Ebene der Organisation: Wird das Team im Sprint unterbrochen, sind Mitglieder mehreren Vorhaben zugeordnet, fehlen Entscheidungen des Product Owners? Vorgehen: Ich würde das Muster in der Retrospektive selbst zum Thema machen und dabei mit Daten arbeiten statt mit Eindrücken, etwa mit der Verteilung der Fertigstellungen über die Sprinttage und dem Anteil ungeplanter Arbeit. Dann würde ich mit dem Team eine Hypothese wählen und eine einzige Änderung ausprobieren, statt fünf Maßnahmen gleichzeitig zu beschließen. Wiederholtes Verfehlen ist außerdem oft ein Vertrauensproblem: Wenn ein verfehltes Ziel sanktioniert wird, wird das Team beim nächsten Mal ein beliebig erreichbares Ziel formulieren, und dann ist die Information endgültig verloren. Was ich nicht täte: die Auswahlmenge pauschal reduzieren, ohne die Ursache zu kennen, oder das Sprint-Ziel abschaffen, weil es ohnehin nicht erreicht wird.