Langwierige Sprint Plannings? Optimiert euer Product Backlog Refinement – mit diesen 3 Fragen
Wie lange dauert das Sprint-Planning in deinem Team?
Falls deine Antwort „weniger als vier Stunden“ lautet, benötigst du diesen Beitrag vermutlich nicht.
Für alle anderen gilt: Es bestehen gute Chancen, dass sich durch die Verbesserung des Product Backlog Refinements das Sprint Planning erheblich verkürzen lässt.
Wie gelingt uns ein gutes Product Backlog Refinement?
Durch das Stellen kritischer Fragen kann das Product Backlog Refinement verbessert werden. Das hat den unschlagbaren Folgeeffekt, dass auch das nächste Sprint Planning deutlich einfacher und schneller abgeschlossen werden kann.
Folgende drei Fragen habe ich im Product Backlog Refinement als besonders hilfreich erlebt.
- 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.
Das Sprint Planning sollte nicht länger als 4 Stunden dauern
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.
3 Fragen für die Optimierung deines Product Backlog Refinements
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 kann uns Planning Poker liefern.
Planning Poker
Mit dieser Methode entwickeln Scrum-Teams auf spielerische Weise ein gemeinsames Verständnis über den Umfang eines Product-Backlog-Eintrags.
So funktioniert’s:
Alle Entwickler erhalten ein Set identischer Karten, meist mit Zahlen aus der Fibonacci-Reihe. Zunächst wählt das Team einen früheren Backlog-Eintrag, der erfolgreich in einem Sprint abgeschlossen wurde und für die typische Teamarbeit repräsentativ ist. Diesem Referenzeintrag wird eine feste Größe zugewiesen, zum Beispiel „21“.
Anschließend stellt der Product Owner den neuen Eintrag vor. Die Entwickler schätzen, wie aufwändig dieser im Vergleich zum Referenzeintrag ist. Ist er komplexer, wird eine höhere Zahl gewählt – erscheint er einfacher oder ähnlich umfangreich, fällt die Zahl entsprechend kleiner oder gleich aus.
Gespielt wird so lange, bis sich das Team auf eine gemeinsame Einschätzung geeinigt hat.
Wichtig: Planning Poker birgt in seiner Einfachheit auch Tücken. – Wer tiefer einsteigen möchte, dem empfehle ich meinen Artikel „Die verborgene Psychologie hinter Planning Poker“.
Es gibt auch alternative Schätzmethoden zum Planning Poker. So z.B. die 3-Eimer-Schätzung, deren Vorteile in diesem Beitrag von Pascal Gugenberger vorgestellt werden.
Wird die Frage nach dem Aufwand eines Backlog-Eintrags vorbereitend bereits im Refinement gestellt und geklärt, kann das Team frühzeitig erkennen, ob ein Eintrag zu groß für einen Sprint ist – und ihn rechtzeitig aufteilen. Das spart wertvolle Zeit im Sprint Planning und bringt Klarheit für die Umsetzung.
Frage 2: Wie können wir diesen Eintrag zerteilen, um früher fertig zu werden?
Die Hamburger-Methode
Um große Product-Backlog-Einträge handhabbarer zu machen, hat sich die sogenannte Hamburger-Methode bewährt – eine Technik, die von Gojko Adzic entwickelt wurde. Ich setze sie auch im „Professional Scrum Product Backlog Management Skills“-Training gemeinsam mit den Teilnehmenden ein, um Probleme und Fragen zu klären, die einer Umsetzung im Wege stehen.
Und so funktioniert die Hamburger-Methode Schritt für Schritt:
- Identifizierung von Schritten: Zunächst zerlegen wir die Funktionalität in grobe Teilschritte – das sind die „Schichten“ des Hamburgers. So entsteht ein erstes gemeinsames Verständnis darüber, was für die Umsetzung nötig ist.
- Lösungsoptionen sammeln: Für jeden Teilschritt werden nun verschiedene technische Umsetzungsmöglichkeiten gesammelt. Das ergibt mehrere Alternativen pro Schicht – wie unterschiedliche Zutaten im Burger.
- Optionen kombinieren: Anschließend kombinieren wir die Optionen und erstellen daraus eine erste vollständige Version des „Hamburgers“.
- Trimmen des Hamburgers: Was ist das erforderliche Mindestmaß an Qualität pro Schritt? Dazu überprüfen wir die Alternativen und notieren auf den Optionen, wie aufwändig 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 die Frage „Wie können wir diesen Eintrag zerteilen, um früher fertig zu werden?” 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.
Frage 3: Wie können wir früher Feedback von Nutzern einholen?
Eines der zentralen Ziele von Scrum ist es, frühzeitig echtes Nutzerfeedback zu bekommen. Doch genau das gelingt nur, wenn die Einträge im Product Backlog klein genug sind, um innerhalb eines Sprints fertiggestellt und ausgeliefert zu werden.
Das Problem: Selbst kleine Features verursachen Aufwand – durch Planung, UI-Design, Entwicklung, Tests und Dokumentation. Wenn sich nach der Auslieferung herausstellt, dass das Feature keinen Mehrwert bringt, war der gesamte Aufwand vergeblich.
In den meisten Fällen liegt das daran, dass die Umsetzung auf Annahmen basiert, die sich später nicht bestätigen.
Zum Beispiel:
- Wir glauben, dass Nutzer das neue Feature wahrnehmen werden.
- Wir hoffen, dass unsere Dokumentation hilft, das Feature zu verstehen.
- Wir gehen davon aus, dass das Feature ein konkretes Problem der Nutzer löst.
Diese Annahmen lassen sich oft viel früher und kostengünstiger prüfen – ganz ohne vollständige Umsetzung.
Dafür lohnt es sich, im Refinement die Frage zu stellen: „Wie können wir früher Feedback von Nutzern einholen?“
Sie öffnet den Blick für alternative Wege, Annahmen zu testen – und verhindert, dass das Team „blind“ entwickelt.
Hier ein paar hilfreiche Methoden:
- Nutzerinterviews: Durch gezielte Gespräche lassen sich Bedürfnisse und Erwartungen der Nutzer frühzeitig aufdecken.
- Beobachtungen: Wenn Nutzer bei der Nutzung bestehender Lösungen beobachtet werden, werden echte Herausforderungen sichtbar.
- Umfragen: Sie liefern quantitative Daten und helfen, Hypothesen zu validieren.
Je mehr Annahmen das Team bereits im Refinement überprüft, desto klarer wird, was und warum etwas entwickelt werden soll. Dieses gemeinsame Verständnis erübrigt Diskussionen im Sprint Planning und ermöglicht einen zielgerichteten Ablauf.
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“.
Mit einem klugen Product Backlog Refinement zur schnelleren Wertsteigerung
Ein langes Sprint Planning ist oft ein Zeichen dafür, dass das Product Backlog Refinement optimiert werden sollte. Wer die drei Fragen – Können wir das in einem Sprint abschließen?, Wie können wir früher fertig werden?, Wie holen wir früher Feedback ein? – konsequent im Product Backlog Refinement stellt, schafft die nötige Klarheit und Struktur schon vor dem Planning. Das verkürzt nicht nur das Event selbst, sondern erhöht auch die Qualität der Zusammenarbeit und die Wahrscheinlichkeit, echten Wert zu liefern. Ein gutes Refinement sorgt dafür, dass das Team im Sprint Planning fokussiert bleibt – auf das Ziel, die Umsetzung und das, was wirklich zählt: schneller Wert für die Nutzer.
Weiterführende Artikel:
Product Backlog Refinement & Sprint Planning
Product Backlog Refinement: 5 konkrete Strategien für diese essenzielle Product-Management-Aktivität von S. Flossmann
Example Mapping – mein Geheimtipp für produktiveres Product-Backlog-Refinement von P. Gugenberger
Wie du das Sprint Planning gestaltest, ohne noch mehr Zeit im Meeting zu verschwenden von S. Flossmann
