Agile Toolbox: Story Time

Backlog Refinement Meetings können schnell zäh und unbefriedigend werden, wenn man 20 Stories in zwei Stunden durcharbeiten muss. In diesem Artikel stelle ich ein etwas angepasstes Format vor, mit dem es möglich ist, mit 100 % Energie jede Story zu bearbeiten und dabei noch die Flexibilität der Planung zu steigern: die Story Time. Kurz gesagt, eine Story Time ist eine tägliche 10-Minuten-Timebox nach dem Daily, die für das Refinement genau eines Items genutzt wird. In diesem Artikel werde ich auf die Grundregeln eingehen und dann basierend auf meinen Erfahrungen damit eine Übersicht über Vor- und Nachteile erarbeiten.

Das Problem

Scrum Teams wenden in der Regel circa 10 % der Sprintzeit für das Refinement des Backlogs auf. Die Empfehlung wurde zwar aus dem Scrum Guide entfernt, ist aber immer noch weit verbreitet. Aus meiner Erfahrung als auch der anderer Kollegen handelt es sich dabei in der Regel bei Zwei-Wochen-Sprints um ein bis zwei einstündige Termine (teilweise auch zweistündige).

In diesen Backlog Refinement Meetings präsentiert die PO dem Team Backlog Items. Im gemeinsamen Dialog werden diese besprochen und bearbeitet, bis sie die Definition of Ready (DoR) des Teams erfüllen. Im Idealfall sind alle Kollegen konstant in die Diskussion involviert, um alle möglichen Aspekte einzubringen. In der Realität ist es in solchen Terminen oft der Fall, dass einige wenige zu bestimmten Items etwas beitragen und die anderen eher still teilnehmen und eventuell beim Schätzen (falls praktiziert) mit eingreifen. Dies führt aufgrund eigener Erfahrungen und Feedback von Teilnehmern zu sehr trägen, ermüdenden und besonders ineffizienten Meetings. Die letzten Items werden oft einfach nur noch durchgeschoben, um den Termin schnell zu Ende zu bringen oder aber noch die gewünschte Anzahl an Items abzuarbeiten.

Foto von Andrea Piacquadio von Pexels

Um die Termine zu optimieren, habe ich Refinements mehrerer Teams analysiert und herausgefunden, dass die durchschnittliche Zeit für ein Item sich bei knapp unter zehn Minuten einpendelt. Eine Diskussion später entstand der erste Versuch für die zehn Minuten Story Time. Viele weitere sollten folgen. 

Um die Termine möglichst kurz und effizient zu gestalten, starte ich in den Teams in der Regel mit einem sehr restriktiven Regelwerk. Wenn das Team einige Erfahrung damit gesammelt hat, passt es den Termin teilweise leicht an, eben inspect and adapt .

Die Regeln:

1. Jeden Tag direkt nach dem Daily findet eine zehnminütige Story Time statt. Hierdurch findet kein Extra-Termin im Kalender mehr statt. Die Kollegen sind durch das Standup gerade zusammen aktiv und nutzen die Energie für weitere zehn Minuten.
2. Es wird genau ein Item bearbeitet. Ist die Story schnell bearbeitet, kann direkt zur täglichen Arbeit übergegangen werden.
3. Wenn es sich abzeichnet, dass das Item nicht innerhalb der Timebox abgeschlossen werden kann, unterbricht ein Zeitnehmer (z. B. der Scrum Master) die Diskussion nach ca. acht Minuten. Die letzten beiden Minuten werden dafür genutzt, Analysen/Fragen/etc. auf der Story zu vermerken, so dass die fehlenden Informationen asynchron besorgt werden können. Dann kann das Item an einem anderen Tag weiter bearbeitet werden. Alternativ ist es oft sinnvoll, sehr große User Stories (vielleicht ist es ja sogar ein verstecktes Epic) in der Timebox lediglich in kleinere Stories zu schneiden, um die einzelnen dann in weiteren Story Times zu bearbeiten.

Die Vorteile:

Die Vorteile für die PO liegen auf der Hand. Sie ist deutlich flexibler und kann schneller auf neue Anfragen von Stakeholdern oder neue Informationen reagieren, da sie täglich neu bestimmen kann, welches Backlog Item besprochen werden soll. Stories, welche die PO kurz vor einer neuen Iteration erreicht haben, passten oft nicht in den Refinement-Zyklus. Sie mussten entweder im Planning besprochen werden oder um mindestens einen Sprint verschoben werden. Mit den Story Times ist es möglich, diese noch zu besprechen und im Idealfall in den nächsten Sprint zu planen.
Die Energie sinkt nicht. Selbst mit einem voll ausgenutztem Daily von 15 Minuten vor der Story Time ergibt sich eine Gesamtzeit von maximal 25 Minuten. Dies ist im Gegensatz zu ein- oder zweistündigen Terminen ohne Einbußen in der Aufmerksamkeit durchführbar. Der Fokus auf ein Item pro Tag vermeidet den Verlust, der in großen Refinement-Terminen durch den Kontextwechsel zwischen unterschiedlichen Items entsteht und normalerweise stark an der Energie der Teilnehmer zehrt. Dem Grundgedanken des fokussierten und ununterbrochenen Sprints wird besser Rechnung getragen. Es wird ja kein größerer Termin mit starken Kontextwechseln im Sprint verplant. Das Scrum-Team kann sich dadurch voll auf den Sprint fokussieren. Die asynchrone Informationsbeschaffung zwischen Story Times entschlackt den oft verspürten Druck deutlich.

Die Nachteile:

Wie fast alle Werkzeuge ist auch die Story Time kein Allheilmittel. Mehrere zusammengehörige Items müssen auf mehrere Tage getrennt bearbeitet werden. Dies kann zu Redundanzen in den Gesprächen führen, weil sich gewisse Fakten mehrmals in Gedanken neu erarbeitet werden müssen. Wenn das Backlog sehr fragmentiert ist, kann es passieren, dass durch die täglichen Kontextwechsel Informationen vergessen werden, die nicht explizit in der Story verortet wurden. Das Gleiche passiert theoretisch auch mit den großen Refinement-Terminen, fällt da aber oftmals nicht so explizit auf. Dieser Effekt zeigt auf der anderen Seite sehr schön auf, wo es noch implizites Wissen und Kopfmonopole gibt und dass es sinnvoll ist, diese möglichst transparent und persistent zu bearbeiten.
Größere Themen können nicht von Anfang bis Ende bearbeitet werden, da dafür die Timebox zu klein ist. Hier haben sich unterschiedliche Verfahren etabliert. Bei größeren Items haben Teams die Timebox für das rudimentäre Schneiden in kleinere User Stories genutzt, um dann in den folgenden Tagen die einzelnen Teilaspekte zu bearbeiten. Bei extrem großen Themen, wie zum Beispiel einem neuen Produkt oder Thema, ist in der Regel ein Workshop o. ä. (z. B. Kickoff, Story Mapping, Lean Canvas, … ) sinnvoll. Hier kann das Thema gesondert und in Tiefe bearbeitet werden.
Für den PO kann es unter Umständen herausfordernd wirken, sich für ein Item entscheiden zu müssen. Dieser Aspekt wiegt aus Erfahrung in der Praxis nicht so stark, da die deutlich höhere Kadenz der Meetings den Druck von der Entscheidung nimmt. Am nächsten Tag ist dann eben die andere Story dran. 

Fazit:

Bisher hat jedes Team, das vorher mit klassischen Refinements gearbeitet hat, begeistertes Feedback zur Story Time gegeben. Die Vorteile überwiegen in der Praxis klar die Nachteile. Die Flexibilität wird von den POs gelobt und die Teammitglieder freuen sich über einige Meetings weniger.

Foto von Thirdman von Pexels

Dieser Artikel ist Teil der noch losen Reihe “Agile Toolbox” (weitere Artikel habe ich unten verlinkt). Habt ihr Fragen oder Erfahrungen mit diesem oder ähnlichen Formaten? Lasst es uns gerne in den Kommentaren wissen. Wir werden weitere Artikel zu unterschiedlichen agilen Werkzeugen hier auf dem Blog veröffentlichen. Habt ihr vielleicht selbst Themen, zu denen ihr euch Informationen oder Erfahrungsberichte wünscht? Nennt sie uns!

Weitere Artikel aus der Agilen Toolbox:

• Moderationswerkzeug Parkplatz
• Wie uns der positive lösungsorientierte Ansatz zum Ziel bringt
• Event Storming – Gemeinsam die Domäne entdecken
• Tuckmans 4-Phasen-Modell
• Sketchnotes – komplexe Zusammenhänge einfach visualisieren

Bildquellen:

• Foto von Andrea Piacquadio von Pexels
• Foto von Thirdman von Pexels
• Titelbild von fauxels von Pexels
• eigene Zeichnung