Was machen wir mit unfertigen User Stories?

Wer kennt sie nicht, die Frage am Ende eines Sprints: Was machen wir mit dieser halb fertigen User Story? Und diese Frage stellt sich nicht nur Neulingen, sondern auch erfahrenen Scrum-Teams. Am Ende eines Sprints konnte eine Story bzw. ein Backlog Item nicht vollständig abgeschlossen werden, weil beispielsweise die Definition of Done nicht in Gänze erfüllt wurde – das kommt auch in den besten Scrum-Teams vor. Aber wie gehen wir jetzt mit der halb fertigen Lösung um?

Keine halben Sachen

Die Antwort ist sehr simpel: Die Story ist nicht abgeschlossen, also wird sie auch nicht ausgeliefert. In der Scrum-Theorie gibt es keine halb fertigen Stories. Alle Backlog-Einträge, die in einem Sprint nicht abgeschlossen wurden, wandern zurück ins Backlog und gelten als nicht fertig. Sie sind dementsprechend nicht Teil des “potenziell auslieferbaren” Produkts.
Diese Regel macht für erfahrene sowie für unerfahrene Scrum-Teams Sinn, um kein falsches Bild darüber zu vermitteln, dass etwas fertig sein könnte, wenn es das schlussendlich noch gar nicht ist.

Wird diese Regel beachtet, hat dies verschiedene Auswirkungen. Selbst wenn eine Story bereits zu 90 % abgeschlossen ist, wandert sie am Sprintende zurück in das Backlog, ohne dass sie neu vom Team geschätzt wird. Das hat auch zur Folge, dass die bereits geschafften Storypoints nicht in die aktuelle Velocity des Teams mit eingerechnet werden. Eine unfertige Story sollte demnach nicht im Review vorgestellt werden und stattdessen mit all ihren Storypoints zurück in das Backlog wandern. Es wird kein Restaufwand geschätzt, denn die Erfahrung zeigt, dass die letzten 10 % einer Story oftmals deutlich länger dauern, als sie es tun sollten, sobald sie im nächsten Sprint fertiggestellt werden. Dies zeigt sich vor allem dann, wenn einige Tage zwischen dem Sprint Review und dem Wiederaufnehmen der Arbeit an dieser Story lagen. Aus diesem Grund macht es wenig Sinn, den Restaufwand einer Story zu bewerten.

Haben sich im Sprint allerdings neue Erkenntnisse ergeben, die eine Auswirkung auf die Komplexität und den Aufwand der Story haben, dann ist es legitim, den Gesamtaufwand neu bewerten zu lassen.

Es kann aber natürlich trotzdem vorkommen, dass bereits begonnene Tickets schnell im nachfolgenden Sprint beendet werden und die ursprünglich geschätzte Storypoint-Zahl dann anschließend in die Statistik des aktuellen Sprints mit einberechnet wird. Aus diesem Grund wird zur Abschätzung der Möglichkeiten im nächsten Sprint immer eine durchschnittliche Velocity herangezogen, meistens errechnet aus den letzten 3-4 Sprints. Auf diese Weise können potenzielle Schwankungen in der Geschwindigkeit ausgeglichen werden.

Weit verbreitete Missverständnisse

Auch wenn das Scrum-Team der Meinung sein kann, dass es sich die Punkte einer halb fertigen Story verdient hat und dies im Review entsprechend gewürdigt werden sollte, so zeigen sich an dieser Stelle meist die Missverständnisse, die bezüglich Scrum immer noch vorherrschen:

• Das Agile Manifest besagt: “Funktionierende Software ist das wichtigste Fortschrittsmaß” – es kommt also nicht darauf an, wie viel Arbeit geleistet wurde, sondern wie viele Features produktionsreif fertiggestellt und welcher Wert damit geschaffen wurde.
• Es geht nicht darum, Time-Tracking zu betreiben – die Velocity dient vielmehr dazu, dem Product Owner eine Planungsgrundlage zu bieten, was in den nächsten Sprints fertiggestellt werden kann.
• Die Priorisierung der Stories obliegt alleine dem Product Owner – es kann also vorkommen, dass sich Prioritäten ändern und Stories, die es nur knapp nicht in einen Review geschafft haben, irrelevant und niemals ausgeliefert werden.

Ausnahmen bestätigen die Regel

Natürlich sollten die oben aufgeführten Aspekte nicht einfach pauschalisiert werden. Es kann ab und zu in Ordnung sein, unfertige Stories in einem Sprint Review vorzustellen. Das Review ist schließlich dazu da, sich Feedback einzuholen. Da in einem Review oftmals die richtigen Personen für ein solches Feedback anwesend sind, kann es sinnvoll sein, auch Arbeit vorzustellen, die noch nicht zu 100 % erledigt ist. Auf Basis des Feedbacks lässt sich der nächste Sprint beispielsweise besser planen und gewonnene Erkenntnisse mit einbeziehen.

Ich habe auch schon erlebt, dass es sinnvoll sein kann, Stories während eines Sprints zu splitten. Im besten Fall werden sie natürlich vor dem Sprint Planning entsprechend klein formuliert. Dies funktioniert aber nicht immer und erfordert viel Übung und Erfahrung. Ergeben sich während des Sprints nun neue Erkenntnisse, die es erlauben, eine Story aufzuteilen oder eventuell “Follow-up Tasks” zu erstellen, dann sollte das Team diese Möglichkeit in Betracht ziehen. Es kann dazu führen, dass wichtige Teile einer Story im Sprint noch fertiggestellt und im Anschluss dem Product Owner und den Stakeholdern präsentiert werden können, um sich Feedback zu holen.

Apropos Feedback: Die Regel, keine unfertigen Stories im Review zu zeigen, sollte kein Scrum-Team davon abhalten, sich wertvolles Feedback einzuholen. Wenn ihr euch dieses Feedback allerdings auch auf andere Art und Weise holen könnt, dann versucht euch besser an diese Regel zu halten.

Wenn noch Zeit im aktuellen Sprint vorhanden ist und eine neue Story nachgezogen wird, obwohl abzusehen ist, dass sie nicht mehr fertig wird, dann kann auch dies unter Umständen durchaus Sinn machen. Die verbleibende Zeit kann so sinnvoll genutzt werden, um eventuelle Vorarbeiten zu erledigen oder Ideen zu skizzieren. An diesem Vorgehen gibt es nichts auszusetzen. Dennoch sollte immer so wenig wie möglich unvollendete Arbeit am Ende eines Sprints übrig bleiben.

Am Ende des Tages bzw. des Sprints sollte das Team reflektieren, warum eine Story nicht fertig geworden ist. Lag es vielleicht daran, dass die Zusammenarbeit im Team nicht richtig funktionierte oder dass so der Arbeitsfluss aufrecht erhalten werden konnte? Die Retrospektive eignet sich besonders gut dazu, diese Frage zu klären und gemeinsam Lösungen zu finden.

Fazit

Im Review werden nur fertige Stories präsentiert: Diese Scrum-Regel macht durchaus Sinn, weil sie versucht, Teams davon abzuhalten, sich selbst und den Stakeholdern ein falsches Bild ihres Fortschritts zu vermitteln.
Dennoch kann es vorkommen (und manchmal ist es auch sinnvoll), dass Backlog-Einträge am Sprintende nicht fertiggestellt werden können. Dies ist so lange in Ordnung, wie sich die unvollendeten Arbeiten nicht anhäufen. Denn “funktionierende Software” steht immer noch an oberster Stelle und sollte die höchste Priorität bei den Team-Mitgliedern haben.