Sprint Planning: das WAS und WIE für den nächsten Sprint planen
Ziel des Sprint Planning ist es, das Arbeitspensum für den nächsten Sprint zu planen und notwendige Entscheidungen zu treffen.
Das Sprint Planning ist zweigeteilt.
- Sprint Planning 1 (SP1) bestimmt das WAS
- SP2 folgt unmittelbar auf SP1: geplant wird die Menge der Arbeit und WIE die Durchführung geschehen soll
Bei einer Sprint-Dauer von 3 Wochen empfiehlt der Scrum Guide ein Sprint Planning von 6h, bei 2-wöchigen Sprints sollten 4h ausreichen.
Sprint Goal definieren: WAS soll geschehen?
PO und das Team einigen sich auf ein klares und machbares sprint goal: in ein, zwei Sätzen wird als Überschrift das Ziel des Sprint verbal formuliert:
- PO stellt den Scope für den nächsten Sprint mitsamt Akzeptanzkriterien vor
- Das Team klärt das eigene Verständnis für das Sprintziel mit dem PO und entscheidet welche PBIs im nächsten Sprint ausgewählt werden
- Das Scoring, die Schätzung der Komplexität geschieht in einheitslosen Story Points ist entweder schon in einem letzten Refinement geschehen oder geschieht spätestens jetzt
SP2 - das WIE klären
Im SP2 geschieht die grobe Planung der Implementierung für den kommenden Sprint in Tasks. Diese Tasks werden geschrieben und weiter verfeinert.
- das Team zerlegt die ausgewählten Stories in Tasks.
Ein praktikabler Tipp ist ein grobe Plausibilitätsprüfung nach Vierteltagen: ist das zu schaffen? - alle Tasks werden auf einem Task Board für den nächsten Sprint mit Kärtchen verschriftlicht und tagesaktuell mit dem Sprint Backlog synchronisiert.
- ein 2-Tage Puffer für Störungen oder Defekte wird eingebaut. Nützlich ist das für alles, das nicht warten kann ohne das Sprint Goal zu gefährden. Wird dieser Puffer nicht genutzt, werden weitere PBIs in den Sprint gezogen und die Entwicklungskapazität genutzt.
Hindernisse, Impediments, Defects haben eigene Prioritäten — Hindernisse mit höchster Priorität werden immer zuerst behandeln (fix it, don’t manage it).
Ergebnisse des Sprint Planning, SP1 und SP2:
- ein gültiger Sprint Backlog mit Stories und Sprint Tasks ist erstellt
- die Mehrzahl der nötige ntechnische Implementierungsschritte sind als Tasks abgeleitet