Sprint-Abbruch – und nun?

Nichts ist perfekt. Manchmal kommt auch das beste Scrum Team nicht an einem Sprint-Abbruch vorbei. Wann ein Sprint abgebrochen werden sollte (und wann besser nicht), erfährst Du in diesem Artikel. Darüber hinaus gebe ich Dir einige Tipps mit auf den Weg, um das Beste aus der Situation zu machen.

Nur der Product Owner kann einen laufenden Sprint abbrechen. Weil es seine Verantwortung ist, den Wert Eures Produkte zu maximieren, ist diese Vorgabe des Scrum Guides nur logisch. Denn bestenfalls wird ein Scrum Sprint nur dann abgebrochen, wenn das Sprintziel obsolet ist und Euer Sprint keinen Wert mehr für das Produkt stiftet.

Der erste und wichtigste Grund für einen Sprint-Abbruch tritt dann ein, wenn Euer Sprintziel obsolet geworden ist. Das kann durch verschiedenste Ereignisse geschehen. Beispielsweise können sich die Bedingungen Euer Branche oder Marktes radikal verändern, weil ein Mitbewerber ein neues Produkt auf den Markt gebracht hat.

In diesen Fällen ergibt es schlichtweg keinen Sinn mehr, Euer Sprintziel zu verfolgen, womit der gesamte Sprint ebenfalls hinfällig wird.

Zweitens kann es geschehen, dass die Entwickler Eures Scrum Teams unüberwindbare Abhängigkeiten entdecken, die nicht aufgelöst werden können. Das kann beispielsweise eine nicht funktionierende Schnittstelle eines externen Partners sein oder auch fehlende Materialien. (Falls Ihr ein haptisches Produkt herstellt.)

In diesem Fall ist Euer Sprintziel schlichtweg nicht mehr erreichbar, unabhängig davon, was Ihr unternehmt.

Drittens kann es vorkommen, dass sich während des Sprints herausstellt, dass Ihr den Aufwand falsch eingeschätzt habt. Das kann beispielsweise geschehen, wenn Ihr bei Eurem Product Backlog Refinement User Stories oder andere Product Backlog Items nicht genau genug betrachtet habt oder einfach zu optimistisch wart.

Durch den erhöhten Umfang (Scope) kann es passieren, dass der entstehende Nutzen einer neuen Funktion den Aufwand nicht mehr rechtfertigt. Auch in diesem Fall ist es sinnvoll, Euren Sprint abzubrechen.

Ein weiterer guter Grund für einen Sprint-Abbruch ist dann vorhanden, wenn Euer Product Owner wiederholt User Stories, Bugs oder andere hoch-priorisierte Aufgaben ins Sprint Backlog schiebt. Traurigerweise ist dieses Verhalten recht häufig zu beobachten. Es entsteht besonders häufig dann, wenn kein Sprintziel existiert und der laufende Sprint nur ein lose Sammlung von Aufgaben ist, die erledigt werden sollen.

Oft ist der Product Owner in solchen Situationen auch nur ein Proxy Product Owner und hat daher gar keine andere Wahl, als die Entwickler davon zu überzeugen, dass die neuen Aufgaben erledigt werden müssen.

Falls Du Scrum Master bist, ist es Dein Aufgabe, die Ursachen für dieses Problem zu ermitteln. Du solltest Deinen Product Owner fragen, ob er nicht lieber den Sprint abbrechen möchte, statt wiederholt das Sprint Backlog des laufenden Sprints zu verändern.

Neben diesen vier Gründen, die für einen Sprint-Abbruch sprechen, gibt es auch noch einige schlechte Gründe, einen Sprint abzubrechen.

Nicht immer wird es Deinem Scrum Team möglich sein, sein Sprintziel zu erreichen. Sofern es jedoch noch immer das Wertvollste ist, was Dein Team tun kann, ergibt es keinen Sinn, den Sprint abzubrechen. (Nur weil das Sprintziel vielleicht erst zwei oder drei Tage nach dem Sprint-Ende erreicht werden kann.)

Ein weiterer schlechter Grund für einen Sprint-Abbruch sind Kundenprojekte, die in Schieflage geraten sind. In der Praxis ist dieser Fall traurigerweise eher die Regel als die Ausnahme. Die Entwickler Deines Scrum Teams werden dann herangezogen, Probleme eines laufenden Projektes zu beheben, die das Projektteam alleine nicht lösen kann.

Natürlich will niemand Kunden hängen lassen. Aber permanente Störungen des laufenden Sprints durch Kundenprojekte sind ein untrügliches Zeichen dafür, dass es Deiner Organisation (noch) nicht gelungen ist, seine Projekte sauber von der Produktentwicklung zu trennen. Für eine funktionierende Produktentwicklung nach Scrum ist das jedoch zwingend notwendig.

Wenn Ihr Euch in der Situation wiederfindet, Euren Sprint abzubrechen, solltet Ihr einige Dinge beherzigen, um das Beste aus der Situation zu machen. Bestenfalls führt Ihr gemeinsam Sprint Review, Retrospektive und Planning durch, statt einfach nur diverse User Stories im Sprint Backlog auszutauschen.

Sofern es sinnvoll ist, solltet Ihr diejenigen User Stories und Aufgaben, die bereits fertiggestellt wurden, gemeinsam in einer Sprint Review begutachten. (Falls möglich mit Stakeholdern.) Euer Product Owner kann dann entscheiden, ob er sie ins Produkt übernimmt oder nicht.

Zweitens solltet Ihr vor Eurem nächsten Sprint wenigstens eine kurze Sprint Retrospektive durchführen. Für Euer Team ist es wichtig, die Ursachen zu identifizieren, die dazu geführt haben, dass der Sprint abgebrochen werden musste.

Drittens solltet Ihr Euren neuen Sprint mit einem Sprint Planning beginnen. (Und nicht einfach nur User Stories im Sprint Backlog des laufenden Sprints austauschen.)

Wenn ein Sprint-Abbruch notwendig ist, stellt sich häufig die Frage, ob Ihr nun einen neuen Sprint-Zyklus beginnt oder nicht. Grundsätzlich habt Ihr dabei drei verschiedene Optionen.

Welche Option die sinnvollste ist, hängt von verschiedenen Faktoren ab. Option 1 ist sicherlich die sauberste Lösung. Wann immer möglich solltet Ihr Euren neuen Sprint mit der gleichen Sprint-Länge wie bisher durchführen.

Allerdings bringt dieses Vorgehen eine Verschiebung der Scrum Events mit sich. Gerade in großen Organisationen ist es jedoch nicht immer so einfach, diese zu verschieben. (Das gilt besonders für die Sprint Review.) Ein neuer Termin verursacht bei vielen wichtigen Stakeholdern höchstwahrscheinlich Terminkonflikte. Auch wenn Euer Scrum Team Teil eines Scrum Nexus ist, ist es unmöglich, die Scrum Events eines einzigen Teams zu verschieben.

In diesen Fällen bleibt Euch dann nichts anderes übrig, als einen neuen verkürzten oder verlängerten Sprint zu planen.

Falls es immer wieder zu Störungen durch plötzliche Anforderungen kommt, kann es für Euch eine Option sein, die Länge Eurer Sprints zu verkürzen. Es kann gut sein, dass eine einwöchige Iteration für Euer Scrum Team besser funktioniert als eine zweiwöchige. Allerdings solltet Ihr Euch bewusst sein, dass diese Maßnahme zwar helfen kann, aber im Grunde nicht mehr ist als Symptombekämpfung.

Als Scrum Master ist es in solchen Situationen Deine Aufgabe, die Probleme zu erkennen, die zu beständigen Störungen Eures Sprints führen und gemeinsam mit den Managern Eurer Organisation Lösungen zu entwickeln, die diese Störungen verringern oder bestenfalls ganz eliminieren.

Wie Du siehst, gibt es diverse gute und schlechte Gründe für einen Sprint-Abbruch. Ich hoffe, ich konnte Dir einige Tipps mit auf den Weg geben, die Dir dabei helfen, das Beste aus der Situation zu machen.

Falls Du noch Fragen, Ideen, Anregungen oder Kritik zum Artikel hast, hinterlasse mir gerne einen Kommentar hier unten auf der Seite. Ich freu mich auf Dein Feedback!