Hand aufs Herz: Wie lange plant dein Scrum Team einen Sprint?
Wenn es so lange dauert, wie bei mir damals, dann wahrscheinlich viel zu lange.
2018 kam ich neu als Scrum Master zu einem Team. Das Team plante seinen Sprint so:
Das Team wählte eine User Story aus dem Backlog für diesen Sprint aus.
Jeder im Team brach die Story in detaillierte Aufgaben herunter.
Im Anschluss ging das Team alle Aufgaben im Detail durch.
Diese Schritte wiederholten die Teammitglieder für alle Einträge des Product Backlogs, bis ihre Velocity vollständig verplant war.
Wie du dir vorstellen kannst, waren die Schritte 2 und 3 sehr zeitraubend. Das Planen des Sprints beanspruchte den ganzen Montag. Als ich mir in einer Pause einen Kaffee aus der Küche holte, stellte mir jemand die Frage:
„Verschwendet euer Team wieder mal einen ganzen Arbeitstag in einem Meeting?“
Die Zusammenarbeit des Teams in Form eines Meetings ist per se keine verschwendete Arbeitszeit. Mich beunruhigten eher die versteckten Auswirkungen dieser Planungspraxis:
Der Task-break-down war die Hauptaktivität im Sprint Planning. Sollten wir nicht eher die Zeit damit verbringen, uns über das Ziel des Sprints Gedanken zu machen? Was sollte nach dem Sprint für die Nutzer des Produkts besser sein?
Obwohl das Team alle Details minutiös plante, – um nicht zu sagen, dass es sich in endlose Detaildiskussionen verlor – verwarf es häufig am Ende der Woche schon wieder diese Details und diskutierte sie neu.
Kennzahlen liefern keine sinnvollen Auskünfte. Die Cycle-Time-Messung im Sprint Board zeigte nur, wie lange es dauerte, einzelne Aufgaben abzuschließen. Allerdings interessierten sich die Vertriebsmitarbeiter weniger dafür, wann die Testaktivitäten abgeschlossen waren. Sie wollten wissen, wann sie das Feature bei ihren Kunden ankündigen konnten.
Viele Scrum Teams berichten mir, dass die Sprint-Planung in ihrem Team ähnlich abläuft. Die meisten trifft dabei allerdings keine Schuld.
Aus meiner Sicht wird der Scrum Guide häufig einfach missinterpretiert.
Hier zwei weitverbreitete Fehler:
Die Konzepte im Scrum Guide werden nicht vollständig erklärt.
In Scrum Trainings werden die exakten Time-Boxen der Scrum Events unnötig stark hervorgehoben. Ohne zu erwähnen, dass eine Time-Box die maximale Zeit beschreibt. Scrum Teams müssen nicht jeden Sprint 8 Stunden lang planen. Sie sollten lediglich nicht länger als 8 Stunden planen. Time-Boxen ermöglichen dem Team, sich auf eine Sache zu fokussieren.
Es werden nur Abschnitte des Guides gelesen.
Im Abschnitt des Sprint Plannings schreibt der Scrum Guide:
„Für jeden ausgewählten Product‐Backlog‐Eintrag planen die Developer:innen die notwendige Arbeit, um ein Increment zu erstellen, das der Definition of Done entspricht. Dies geschieht oft durch Zerlegung von Product‐Backlog‐Einträgen in kleinere Arbeitseinheiten von einem Tag oder weniger.“
Lesen wir nur diese Sätze des Scrum Guides, dann könnten wir daraus schließen: Die Arbeit für jeden Product‐Backlog‐Eintrag muss detailliert in Aufgaben geplant werden. Lesen wir den Scrum Guide aber vollständig, dann erkennen wir: Scrum ist kein Prozess, sondern ein Rahmenwerk. Scrum ist lediglich ein Rahmen, innerhalb dessen Teams einen Wertschöpfungsprozess erstellen und kontinuierlich verbessern. Darum geht es auch im Kern des Manifests für Agile Softwareentwicklung:
„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen.“
Im Kern geht es also bei Agilität darum, sich kontinuierlich zu verbessern. Dazu müssen wir neue Wege gehen!
Dabei machen wir auch nicht vor dem Sprint Planning halt.
Einige Wochen habe ich mir diese Sprint-Planning-Session angesehen. Dann fasste ich den Entschluss, sie zu verbessern.
In den folgenden Wochen recherchierte und las ich und tauschte mich mit erfahrenen Scrum Mastern aus. Ich wollte das Planning nicht nur zeitlich verkürzen. Es sollte für die Teammitglieder und Stakeholder auch wertvoll genutzte Zeit sein. Daraufhin haben wir im Team viel ausprobiert und ich bin zu folgender Einsicht gekommen:
Solltest du dich auch in dieser Situation wiederfinden, dann stehen die Chancen gut, dass der Sprint Backlog deines Teams die folgende Form hat. Er besteht aus drei Spalten mit den Überschriften:
To-do
Doing
Done
Die Aufgaben der Einträge des Product Backlogs wandern dann im Sprint von „To-do“ nach „Doing“ und schließlich in „Done“. Wenn alle Aufgaben für einen Product-Backlog-Eintrag in „Done“ sind, ist der Eintrag abgeschlossen.
Falls dem so ist, dann ist dein Hebel, um das Sprint Planning effizienter zu gestalten, den Sprint Backlog umzustrukturieren.
Statt den Spalten „To-do“, „Doing“ und „Done“ sollten die Spalten die Aktivitäten im Arbeitsablauf darstellen. Zum Beispiel könnten die Spalten „Entdeckung“, „Design“, „Entwicklung“ und „Validierung“ heißen.
Das hast du richtig gelesen. Das ist die ganze Einsicht.
Bevor ich dir erzähle, welche positiven Auswirkungen die Umstrukturierung auf die Arbeit unseres Teams hatte, erkläre ich dir, wie du auf die richtigen Arbeitsablaufschritte kommst. Das ist einfach und geht schnell. Dazu musst du nur mit deinem Team die Aufgaben der Product-Backlog-Einträge der vergangenen Sprints analysieren. Gehe dazu in vier Schritten vor:
Für jeden Product-Backlog-Eintrag schreibt ihr die Aufgaben auf ein eigenes Post-it.
Breitet alle Aufgaben vor euch aus und gruppiert die Aufgaben.
Vergebt den Gruppen übergreifende Namen, z. B. „Entdeckung“.
Diese Namen bilden die Überschriften der Spalten des neuen Sprint Backlogs.
Ein Beispiel lautet:
Entdeckung: analysieren und recherchieren
Design: designen von API, UI, Testfällen
Entwicklung: Code schreiben, Design gestalten, Testfälle umsetzen, Dokumentation erstellen
Validierung: Code Reviews durchführen und Testfälle ausführen
Welche Auswirkung hat dieser neue Sprint Backlog?
Gleich eines vorweg: Genau genommen haben wir nicht den Sprint Backlog umstrukturiert, sondern die Arbeitsweise des Teams.
Der Sprint Backlog repräsentiert nur den Arbeitsfluss des Teams. Verändern wir den Sprint Backlog, dann verändern wir die Arbeitsweise des Teams. Der Sprint Backlog stellt somit einen großen Veränderungshebel dar.
Das Team verbrachte weniger Zeit im Sprint Planning.
Das Sprint Planning drehte sich jetzt darum, ein lohnendes Ziel für den Sprint zu finden.
Ein Ziel, das beschreibt, was für die Nutzer des Produkts nach diesem Sprint anders sein wird. Und welche Einträge des Product Backlogs nötig sind, um dieses Ziel zu erreichen. Auf den dritten Teil des Sprint Plannings entfiel damit kein großer Anteil mehr. Nach dem Scrum Guide beantwortet das Team im dritten Abschnitt die Frage: „Wie wird die ausgewählte Arbeit erledigt?“ Ein detaillierter Task-break-down war jetzt vorab nicht mehr nötig. Stattdessen zog das Team einen ersten Eintrag des Backlogs in die Spalten und machte sich gemeinsam an die Entdeckungsaufgaben. Nachdem die Entdeckungsphase abgeschlossen war, wanderte der Product-Backlog-Eintrag in die Spalte „Design“ und die Design-Aktivitäten begannen. So durchlief der Eintrag eine Spalte nach der anderen, bis er abgeschlossen war.
Jeder Eintrag im Product Backlog stellte einen Mehrwert dar.
Das Umstrukturieren des Sprint Backlogs machte sich auch im Product Backlog bemerkbar.
Reine Analyseeinträge im Product Backlog passten nicht mehr zum Arbeitsablauf des Teams im Sprint. Einzelne Arbeitsablaufaktivitäten stellten für sich noch keinen Wert für den Anwender dar. Jeder Product-Backlog-Eintrag durchlief jetzt eine Analysephase. Dies führte dazu, dass das Team Einträge im Product Backlog ausschließlich aus der Nutzersicht formulierte. Alle Einträge des Product Backlogs stellten somit potenziellen Wert dar.
Nur die Kombination aus Entdeckungs-, Design-, Entwicklungs- und Validierungsarbeit ermöglichte Mehrwert für die Nutzer.
Vertrieb und Kundenbetreuern fiel es leichter, Vorhersagen zu machen.
Das Vereinheitlichen der Product-Backlog-Einträge hatte noch zwei gravierende Vorteile.
Zum einen fiel es dem Product Owner leicht, die Einträge zu ordnen, da sie alle aus der gleichen Perspektive geschrieben waren. Dadurch waren sie auch alle für die Kollegen des Vertriebs besser zu verstehen. Zum anderen lieferten jetzt Kennzahlen wie die Cycle-Time eines Eintrags verlässliche Informationen für die Kundenbetreuung, wann der Eintrag wahrscheinlich fertig sein würde.
Das Verändern des Sprint Backlogs und somit der Arbeitsweise des Teams hat natürlich viele Fragen aufgeworfen. Im Folgenden findest du die Einwände, mit denen ich konfrontiert wurde, und wie du sie entkräften kannst.
Wenn der Task-break-down nicht im Sprint-Planning stattfindet, machen wir ihn dann im Refinement?
Nein.
Der Zweck von Refinement in Scrum ist nicht, die Arbeit in Aufgaben herunterzubrechen. Der Zweck des Refinement ist, den möglichen Mehrwert für die Nutzer besser zu verstehen. Dabei ist es wichtig, die Arbeit in kleinere Teile zu zerlegen, sodass jeder Teil für sich noch einen Mehrwert hat. Das machen wir so lange, bis jedes Einzelteil innerhalb eines Sprints umsetzbar wird. Der Task-break-down findet nicht mehr explizit statt, sondern implizit bei der Arbeit. Die Einträge wandern von Spalte zu Spalte im Sprint Backlog. Zieht das Team einen Eintrag in eine neue Spalte, dann überlegen die Teammitglieder, was sie jetzt erarbeiten müssen, damit er die Spalte verlassen kann.
Wie viele Einträge wählen wir im Sprint Planning aus?
Daran ändert die Umstrukturierung des Sprint Backlogs nichts. Weiterhin kann dein Team dazu den Durchsatz oder die Velocity des vergangenen Sprints als Entscheidungsgrundlage heranziehen.
Woher wissen wir, wer an was arbeitet, wenn wir keine Aufgaben mehr verwenden?
Scrum ist ein Teamsport.
Das ganze Team ist für das Fertigstellen der Arbeiten verantwortlich. Jeder erfahrene Scrum Master wird dir das bestätigen: Ein Scrum Team ist nicht erfolgreich, wenn jeder Entwickler nur seine Aufgaben abschließt, sondern dann, wenn das Team gemeinsam die Product-Backlog-Einträge fertigstellt.
Wer dazu an was gearbeitet hat, ist am Ende doch unerheblich.
Wie sind wir sicher, dass wir die Aufgaben im Sprint abschließen, wenn wir die Arbeit nicht im Detail im Sprint Planning betrachten?
Gar nicht.
Aber mal Hand aufs Herz: Das garantiert dir auch kein Task-break-down. Die Arbeiten, die Softwareentwickler erledigen, damit ein Eintrag fertiggestellt wird, ist zum großen Teil unbekannt. Die Unbekannten eliminieren wir nicht mit mehr Planung. Unbekanntes lässt sich eben nicht vorhersagen und infolgedessen nicht planen. Wir müssen die Unbekannten entdecken und dazu muss die Arbeit getan werden.
Softwareentwicklung gleicht Bergsteigen: Du bist erst am Ziel, wenn du wieder wohlbehalten unten bist.
Einfachheit ist Schnelligkeit
Als Scrum Master sind wir Change-Agenten.
Über die Jahre bin ich dabei zur Einsicht gelangt: Wenn du bessere Wege erschließen möchtest, um Software zu entwickeln, dann strebe nach Einfachheit. Einfachheit ist Schnelligkeit. Denn je einfacher etwas ist, umso einfacher ist zu verändern.
Ist die Umstrukturierung des Sprint Backlogs nicht die einfachste Lösung, um das Sprint-Planning-Meeting zu verbessern, dann lass dich nicht entmutigen.
Such weiter nach einem einfacheren Ansatz!
Wenn du bereits einen gefunden hast, dann schreibe ihn doch in die Kommentare, damit wir alle davon profitieren können.