Wie man sicher den Scrum Sprint reißt…

Ihr wollt also eine Anleitung zum Reißen von Scrum Sprints geben. Was meint Ihr denn mit: „Wir haben einen Sprint gerissen.“?

Claas: Damit meinen wir, dass wir einen Sprint nicht erfolgreich abschließen konnten. Wir haben nicht geschafft, was wir uns für den Sprint vorgenommen haben. Das ist uns eine Weile lang im Team Spectre am laufenden Band passiert. Da haben wir als Team eine echt schlimme Phase hinter uns. Über einen Zeitraum von fast drei Monaten haben wir einen Scrum Sprint nach dem anderen gerissen.

Was genau ist denn so schlimm daran?

Jenny: Naja: Mehrere Sprints in Folge reißen bedeutet, dass man über einen längeren Zeitraum keine Glücksgefühle zum Sprintende hat. Genau das ist aber ein sehr wichtiger Aspekt in der Psychlogie des Scrum Framework. Man hält als Team nur eine längere Projektlaufzeit aus, wenn man in relativ kurzen Abständen Erfolgserlebnisse hat. Ein Vorteil der kurzen Sprintdauern. Da unsere Erfolgserlebnisse ausblieben hat es uns in dieser Phase ordentlich runter gezogen.

Wie seid ihr aus dieser Phase herausgekommen?

Christine: Wir haben immer wieder in der Sprint Retrospektive hinterfragt, wie es zu dem gerissenen Sprint kam. Rückblickend haben wir 5 Fehler identifiziert, die dazu geführt haben, dass wir so viele Sprint in Folge in den Sand gesetzt haben.

Und welche Fehler waren das?

Alexander: Fehler #1: Wir haben nicht nachverhandelt bei gravierenden Veränderungen im Laufe eines Sprints. Das Sprint Backlog war quasi in Stein gemeißelt. Wir haben lange gar nicht gewusst, dass das Sprint Backlog überhaupt nachverhandelt werden kann.

So haben wir am geplanten Sprint Backlog festgehalten, auch wenn beispielsweise durch Krankheitstage von Kollegen Sprint Kapazität weggefallen ist. Es war schlicht nicht mehr realistisch das gesamte Sprint Backlog umzusetzen. Trotzdem haben wir als Entwicklungsteam nicht mit unserem Product Owner
zusammen überlegt was wir aus dem Sprint Backlog herausnehmen können, um das Sprint Backlog an die verbliebene Sprint Kapazität anzupassen.

Stefan: Vergleichbar damit ist es uns auch einige Male passiert, dass wir uns bei User Stories deutlich verschätzt haben. Der Aufwand eine User Story umzusetzen war deutlich größer, als angenommen. Dadurch wurde es unmöglich das geplante Sprint Backlog im Sprint umzusetzen. An sich ist das nichts schlimmes. Aber durch die fehlende Nachverhandlung des Sprint Backlogs haben natürlich auch diese Sprints gerissen. Das Sprint Backlog bei gravierenden Veränderungen nicht nachzuverhandeln war für uns quasi die Garantie zum Unglücklich sein!

Was bedeutet denn „das Sprint Backlog nachzuverhandeln“?

Torsten: Eigentlich ist das eine ganz einfache Sache: Wenn Sprint Kapazität wegbringt oder man sich sehr verschätzt hat bei einer oder mehreren User Stories nimmt man von den unterste Einträge im Sprint Backlog so viele raus, bis das verbliebene Sprint Backlog wieder zur Sprint Kapazität passt.

Das heißt das Nachverhandeln bedeutet immer User Stories rausnehmen aus dem Sprint?

Torsten: Nein, nicht zwingend. Im umgekehrten Fall ist natürlich das Nachziehen von User Stories in den laufenden Sprint genauso möglich. Also dann, wenn User Stories überschätzt wurden und viel schneller umgesetzt werden konnten als angenommen oder überraschend doch mehr Sprint Kapazität zur Verfügung steht als geplant. Nachziehen ist aber natürlich deutlich einfacher, da muss man seinen PO nicht lange überzeugen. 🙂

Jenny: Grundsätzlich ist der Scope die einzig zulässige Stellschraube im Scrum Framework. Das ist hier näher erläutert. Das bedeutet aber nicht zwingend, das ganze User Stories aus dem Sprint genommen werden müssen. Manchmal reicht es auch eine User Story nachträglich kleiner zu schneiden, sie also in mehrere User Stories aufzuteilen. Den einen Teil setzt man dann wie geplant im Sprint um, den anderen Teil verschiebt man in einen Folgenden Sprint. Aber auch von dieser Möglichkeit haben wir lange keinen Gebrauch gemacht, sondern sehenden Auges Sprints an die Wand gefahren.

Das war also Fehler #1. Welche Fehler habt ihr noch identifiziert?

Stefan: Fehler #2 war: Wir haben das Sprintziel nicht ernsthaft eingesetzt. Das Sprintziel zu erreichen entscheidet darüber, ob ein Sprint erfolgreich war oder nicht. Das bedeutet: Selbst wenn nicht alle geplanten User Stories umgesetzt wurden kann das Sprintziel erreicht sein. Nämlich dann, wenn nicht alle geplanten User Stories auf das Sprintziel einzahlen. Hätten wir uns auf das Sprintziel fokussiert, hätten wir einige Sprints doch als erfolgreich abgeschlossen betrachtet und hätten unser Erfolgserlebnis gehabt.

Was noch?

Claas: Fehler #3: Wir waren uns an einem Punkt sehr sicher, einige Effizienz-Potential gehoben zu haben. Schon fast aus Trotz wegen der zuvor gerissenen Sprints haben wir uns deutlich mehr Story Points für den Sprint vorgenommen als zuvor. Wir wollten einen Sprung in unserer Velocity machen.
Leider hatten wir uns etwas zu viel vornehmen für den Sprint. Vor lauter Stolz konnten wir das aber nicht zugeben. Wir wollten es zwingen… Statt also rechtzeitig wieder etwas aus dem Sprint Backlog heraus zu nehmen haben wir es versucht hinzukriegen und dadurch den nächsten Sprint gerissen.

Und was war Fehler #4?

Christine: Fehler #4 war: Wir haben aus Frust über die gerissenen Sprints irgendwann aufgehört unser Burndown Chart zu pflegen. Wir waren der Meinung, dass es uns eh nichts bringt. Die Sprints rissen wir ja trotz des Burndown Charts. Das führte aber dazu, dass wir so den Überblick verloren und weitere Sprints gerissen haben. Einfach weil wir zu spät gemerkt haben, dass Sprints aus dem Ruder laufen und wir so nicht frühzeitig reagieren konnten. Wir reden die ganze Zeit davon ggf. das Sprint Backlog nach zu verhandeln. Das sollte möglichst früh im Sprint passieren wenn noch Zeit bleibt zu reagieren. Dafür braucht man eine Entscheidungsgrundlage. Und die ist das Burndown Chart. Läuft der Sprint deutlich aus dem Trend muss man sich als Scrum Team fragen: Können wir das noch mit hoher Wahrscheinlichkeit aufholen im Sprint oder nicht? Wenn nein, dann muss nachverhandelt werden.

Ok. Vier Eurer fünf identifizierten Fehler haben wir gehört. Welcher ist der letzte?

Alexander: Fehler #5: Sprints wurden nicht abgebrochen, obwohl das Sprintziel obsolet war. Es ist selten vorgekommen, aber: wir hatten den Fall, dass das Sprintziel aufgrund der Veränderung von äußeren Rahmenbedingungen einfach nicht mehr aktuell war. Für den Fall sieht das Scrum Framework vor, dass der Product Owner den Sprint abbrechen kann. Das war uns als Team zunächst gar nicht klar, dass es ok ist den Sprint abzubrechen. Im zweiten Fall wollte unser PO es leider nicht einsehen, dass das Sprintziel obsolet geworden ist. Obwohl unser Scrum Master und wir Entwickler ihn darauf hingewiesen und zum Sprint-Abbruch geraten haben.
Im Ergebnis standen wir wieder da mit einem erfolglosen Sprint.

Was würdet ihr zusammenfassend anderen Scrum Teams raten?

Jenny: Seid Euch bewusst, dass der Scope bzw. die Breite des Scopes die einzig zulässige Stellschraube ist im Agilen Umfeld. Man braucht eine Stellschraube im auf unvorhersehbares reagieren zu können. Nutzt diese Stellschraube und verhandelt das Sprint Backlog nach, wenn nötig. Plant etwas konservativer, bis die Sprints laufen. Etwas in Sprint Backlog nachziehen könnt ihr immer.

Torsten: Das sollte aber schon die Ausnahme sein, nicht zum Regelfall werden. Ist es regelmäßig erforderlich nachzuverhandeln stimmt etwas nicht. Dann guckt in der Retro auf Euer Scrum.

Claas: Formuliert ordentliche, aussagekräftige Sprint Ziele und messt den Sprinterfolg ausschließlich daran. Ist das Sprint Ziel erreicht oder nicht? Nur das zählt.

Stefan: Nehmt Euch nicht zu viel auf einmal vor, wenn ihr im nächsten Sprint die Velocity steigern wollt. Und seid nicht zu stolz wieder etwas raus zu nehmen wenn es zu viel war.

Christine: Pflegt Euer Burndown Chart in jedem Sprint. Auch in Phasen in denen es nicht zu gut läuft. Es ist wichtig den Überblick zu behalten.

Alexander: Brecht Sprints ab, wenn das Sprintziel nicht mehr erreichbar ist. Lieber ein Ende mit Schrecken. Mund abwischen und einen neuen Sprint planen, statt in Untätigkeit zu verharren und auf das Ende eines kaputten Sprints zu warten.