Wie lange dauert die Planung eines Sprints in deinem Team?
Falls deine Antwort „weniger als vier Stunden“ lautet, ist dieser Beitrag leider nicht für dich bestimmt.
Für alle anderen gilt: Es bestehen gute Chancen, dass wir durch die Verbesserung des Product Backlog Refinements das Sprint Planning erheblich verkürzen können.
Wie lässt sich das Product Backlog Refinement verbessern?
Durch das Stellen kritischer Fragen kann das Product Backlog Refinement verbessert werden. Drei solcher Fragen möchte ich in diesem Artikel vorstellen:
- Können wir diesen Eintrag innerhalb eines Sprints abschließen?
- Wie können wir diesen Eintrag zerteilen, um früher fertig zu werden?
- Wie können wir früher Feedback von Nutzern einholen?
Bevor ich die Fragen im Detail erläutere, möchte ich erklären, warum ich sie als „kritisch“ betrachte und warum dieser Artikel für Teams gedacht ist, die mehr als vier Stunden im Sprint Planning verbringen.
Die drei Fragen sind kritisch, um früher Wert zu liefern, – ein Versprechen, das Unternehmen mit der Nutzung von Scrum einlösen möchten. Sie sind auch kritisch, um die Zeit, die das Team für das Sprint Planning aufwendet, zu verkürzen. Übermäßige Planung am Stück ist Verschwendung von Teamkapazität. Der Scrum Guide warnt mit dieser Regel davor:
„Das Sprint Planning ist zeitlich auf maximal acht Stunden für einen einmonatigen Sprint beschränkt. Bei kürzeren Sprints ist das Event entsprechend kürzer.“
Kurz gesagt: Ein Scrum Team sollte nicht mehr als acht Stunden für die Planung eines Sprints aufwenden.
Das bedeutet nicht, dass Scrum Teams ihre Arbeit nicht häufiger im Sprint planen dürfen oder dass sie nicht regelmäßig umplanen sollten, wenn sich neue Erkenntnisse ergeben. Und es bedeutet sicherlich auch nicht, dass Scrum Teams ihre langfristige Planung mit Stakeholdern im Sprint Review aufgeben sollten.
Es bedeutet lediglich:
Nach mehr als acht Stunden der Planung, wie ein Feature konkret umgesetzt werden kann, ist es wertvoller, mit der Umsetzung zu beginnen und etwaige Probleme zu lösen, wenn sie wirklich auftreten. Meiner Erfahrung nach sind vier Stunden Sprint Planning ein guter Kompromiss aus Fokussierung und inhaltlicher Tiefe. Fokussierung auf die Formulierung eines Sprint-Ziels, das einen Leitstern für die gesamte Arbeit im Sprint darstellt. Gleichzeitig bieten die vier Stunden genügend Zeit, um bei dem Product-Backlog-Eintrag, der als Erster dafür umgesetzt werden soll, die Details der Implementierung zu planen.
Nun zu den Fragen: Stelle diese Fragen vor dem Sprint Planning, um die Verfeinerung des Product Backlogs anzustoßen. Den Erfolg deiner Initiative kannst du dann an der Dauer des Sprint Plannings erkennen.
Frage 1: Können wir diesen Eintrag innerhalb eines Sprints abschließen?
Die Antwort darauf gibt das Planning Poker.
Es unterstützt Scrum Teams dabei, Product-Backlog-Einträge zu verstehen und ein gemeinsames Verständnis über deren Umfang zu erlangen. Das Modell hierfür ist eine Pokerrunde.
Hier sind die Regeln:
- Jeder Entwickler erhält identische Karten, die üblicherweise Zahlen der Fibonacci-Reihe aufweisen.
- Das Team wählt aus den vergangenen Sprints einen Eintrag aus, der innerhalb eines Sprints fertiggestellt wurde, an dem möglichst viele Entwickler beteiligt waren und der repräsentativ für die Arbeit des Teams ist. Diesem Eintrag wird eine Größe zugeordnet (z. B. 21).
- Der Product Owner präsentiert den zu schätzenden Eintrag aus dem Product Backlog.
- Die Entwickler schätzen den Eintrag, indem sie ihm eine Größe zuordnen, basierend auf dem Referenzeintrag. Glauben sie, dass der Eintrag größer ist, vergeben sie eine größere Zahl als 21. Glauben sie, dass der Eintrag kleiner oder gleich groß ist, wählen sie eine kleinere Zahl oder die 21.
Die Entwickler setzen das Planning Poker fort, bis ein gemeinsames Verständnis über den Product-Backlog-Eintrag erreicht ist.
Planning Poker kann tückisch sein und birgt viele versteckte Fallstricke. Um dabei nicht zu stolpern, empfehle ich meinen Artikel „Die verborgene Psychologie hinter Planning Poker: So vermeidest du 3 typische Fallstricke und steigerst die Schätzgenauigkeit!“.
Indem du die Frage nach der Größe eines Product-Backlog-Eintrags vor dem Sprint Planning stellst, hilfst du deinem Team zu erkennen, ob die Arbeit möglicherweise zu groß für einen Sprint ist. Sollte dies der Fall sein, könnt ihr sie noch vor dem Sprint Planning zerteilen und so im Sprint Planning Zeit sparen.
Nun zur nächsten Frage:
Frage 2: Wie können wir diesen Eintrag zerteilen, um früher fertig zu werden?
Eine Methode, diese Frage zu beantworten, ist die Hamburger-Methode.
Sie wurde von Gojko Adzic entwickelt. Ich möchte hier eine Variante vorstellen, die ich auch den Teilnehmern im „Professional Scrum Product Backlog Management Skills“-Training nahebringe. Im Training beschränken wir uns nicht nur auf die Vorstellung, sondern wenden sie auch gemeinsam an. So können wir alle Probleme und Fragen klären, die einer Umsetzung im Team im Wege stehen.
Hier die Schritte im Überblick:
- Identifizierung von Schritten: Zuerst zerlegen wir die Funktionalität in übergeordnete Schritte, um zu verstehen, was für diesen Product-Backlog-Eintrag getan werden muss. Diese Schritte bilden die Schichten des Hamburgers zwischen den Brötchen.
- Identifizierung anderer Optionen: Das Team erarbeitet verschiedene Optionen, wie die einzelnen Schritte technisch umgesetzt werden können. Nach diesem Schritt verfügen wir für jeden Schritt über mehrere technische Lösungsmöglichkeiten.
- Kombination aller Optionen: Nun kombinieren wir alle alternativen Optionen und erstellen den Hamburger.
- Trimmen des Hamburgers: Wir entscheiden uns für das erforderliche Mindestmaß an Qualität pro Schritt. Dazu überprüfen wir die Alternativen und notieren auf den Optionen, wie aufwendig die Umsetzung wäre. Wir können auch Optionen aussortieren, die ungefähr den gleichen Aufwand erfordern und austauschbar sind.
- Ersten Bissen nehmen: Schließlich entscheiden wir, wie die erste Version des Product-Backlog-Eintrags aussehen soll, – das ist der erste Bissen. Indem wir die Alternativen im Hamburger markieren, erhalten wir auch einen Überblick über mögliche zukünftige Aktualisierungen des Features.
Stelle deinem Team diese Frage zu jedem Eintrag im Product Backlog und nutze die Hamburger-Methode, um die Einträge zu zerteilen. Wenn dies vor dem Sprint Planning geschieht, vermeidet ihr endlose Diskussionen über Umsetzungsalternativen während des Sprint Plannings.
Nun zur letzten Frage:
Frage 3: Wie können wir früher Feedback von Nutzern einholen?
Das Ziel von Scrum ist es, früher fertig zu werden, um schneller Feedback zu erhalten.
Eine Grundvoraussetzung dafür sind kleine Einträge. Je kleiner ein Eintrag, desto besser, denn kleine Einträge lassen sich innerhalb eines Sprints abschließen und an den Kunden ausliefern. Erst wenn die Nutzer das Feature wirklich nutzen, erfahren wir, ob es tatsächlich Wert stiftet.
Allerdings ist mit der Lieferung immer ein erheblicher Kostenaufwand verbunden. Die Arbeiten müssen im Sprint Planning geplant, das User-Interface entworfen, das Feature programmiert, die Funktionalität getestet und die Dokumentation erstellt werden. Unabhängig davon, wie klein der Eintrag im Product Backlog auch geschnitten wird, diese Kosten gehen niemals auf null. Und wenn das Feature nicht nützlich ist, ist seine Entwicklung als Verschwendung anzusehen.
Dass ein Feature nicht nützlich ist, liegt zu 99 % daran, dass wir die Entwicklung auf Annahmen basieren, die sich später nicht bewahrheiten.
Wir nehmen an,
- dass durch dieses Design die Nutzer auf das Feature aufmerksam werden,
- dass diese Funktionalität ein Problem unserer Nutzer löst und
- dass die Dokumentation den Nutzern hilft, das Feature zu verstehen.
Diese Annahmen lassen sich jedoch häufig viel kostensparender überprüfen, als wenn das Feature vollumfänglich entwickelt und an die Benutzer ausgeliefert wird.
Die Einladung, Möglichkeiten hierfür zu ergründen, lautet:
„Wie können wir früher Feedback von Nutzern einholen?“
Diese Frage lädt dazu ein, die Annahmen, die wir in der Entwicklung treffen, zu hinterfragen und nach Wegen zu suchen, diese Annahmen frühzeitig zu überprüfen.
Hier sind einige Methoden, wie du deinem Team helfen kannst, Annahmen zu überprüfen:
- Nutzerinterviews: Durch direkte Gespräche mit Nutzern versucht das Scrum Team, deren Bedürfnisse, Erfahrungen und Einstellungen zu verstehen, indem es gezielte Fragen stellt und die Antworten analysiert.
- Nutzerbeobachtungen: Bei Nutzerbeobachtungen werden Nutzer dabei beobachtet, wie sie spezifische Aufgaben ausführen. Dies hilft, Probleme in der Benutzerfreundlichkeit zu identifizieren und Verbesserungen vorzuschlagen.
- Umfragen: Eine quantitative Forschungsmethode, bei der durch die Verteilung von Fragebögen an eine große Gruppe von Nutzern Daten gesammelt werden, um Meinungen, Präferenzen und Verhaltensweisen in Bezug auf ein Produkt oder eine Dienstleistung zu erfassen.
Mehr dazu, wie du Annahmen frühzeitig überprüfen kannst, findest du in meinem Artikel „Kein UX-Designer im Team? Mit diesen 3 einfachen Techniken kann dein Scrum Team noch heute mit UX-Research beginnen“.
Die Überprüfung von Annahmen wirkt sich auch positiv auf das Sprint Planning aus. Je mehr Annahmen im Refinement vom Scrum Team überprüft wurden, desto besser verstehen die Entwickler die Nutzer, deren Probleme, Bedürfnisse und die möglichen Lösungen. Dieses gemeinsame Verständnis macht Diskussionen im Sprint Planning darüber, warum ein Feature entwickelt werden soll, überflüssig.