Scrum für Dummies: Im Sprint Planning wird auch gepokert!

Felix schwört auf Planning-Poker

Letzten Monat erklärte uns Felix, Agile Master aus dem Team Valiton, wie die Vision und die Product Backlog Items eines Software-Projekts zustande kommen. Um es für Dummies verständlicher zu machen, hat Felix dies anhand eines realen Projektes beschrieben: GROW – Die 360 Grad-Datenbank für die Verlage des Konzerns Hubert Burda Media.

Heute erklärt er uns, was im Sprint Planning passiert. Los geht´s.

Aus Product Backlog wird Sprint Backlog

Ziel des Sprint Plannings ist es, die Items aus dem Product Backlog zu extrahieren, die innerhalb des nächsten Sprints vom Developement Teams bearbeitet werden.

Zu Beginn des Sprint Plannings definiert der Product Owner ein Sprint-Ziel, welches mit dem Abschluss des Sprints erreicht werden soll. Im praktischen Beispiel 360 Grad Toolbox für die Verlage von Hubert Burda Media war z. B. ein Sprint-Ziel, die SSO-Datenbank so zu stabilisieren, dass User einen performanteren Zugriff auf die Toolbox haben und um nervige Wartezeiten zu verhindern.

Allerdings müssen nicht alle Sprint Backlog Items zur Erreichung des Sprint-Ziels beitragen, hier sind wir flexibel. Es können auch Items im Sprint enthalten sein, die nichts mit dem Sprint-Ziel zu tun haben. Diese stehen allerdings in zweiter Reihe und werden bei unvorhergesehen Situationen (Spontanen Workshops, Krankheiten etc.) aus dem Sprint Backlog gekickt.

Auf Basis der Priorisierung, der Größe der einzelnen Backlog Items und der sog. Velocity* wählt das Development Team gemeinsam mit dem Product Owner nun die Items aus, welche im nächsten Sprint umgesetzt werden sollen. Oberstes Gebot: Die Backlog Items, welche im bevorstehenden Sprint bearbeitet werden sollen, müssen der Definition of Ready entsprechen.

Es wird gepokert

Die Anzahl der Story Points jedes Items bestimmt das Development Team mit einem Planning-Poker. Bei dieser Methode erhält jedes Team-Mitglied Planning-Poker-Karten, die die möglichen Story Points abbilden (1, 2, 3, 5, 8, 13, 20, 40, 100). Jedes Team-Mitglied bewertet die Komplexität eines Items und setzt diese in Relation zu anderen Items. Grundsätzlich gilt, je größer die Zahl, desto komplexer aber auch teilweise unschärfer ist ein Item. Die Karten werden verdeckt „gespielt“. Erst wenn alle Mitglieder sich für einen Wert entschieden haben, werden die Karten aufgedeckt (So wird verhindert, dass sich die Schätzungen beeinflussen). Weichen die Einschätzungen der Mitglieder zu stark voneinander ab, müssen mehr Informationen zum Item gesammelt werden. Die Mitglieder diskutieren dann, was konkret zu tun ist, um das Item umzusetzen und ergänzen das Item um weitere Information. Diese Diskussionen sind super-hilfreich, da so neue Sichtweisen und Interpretationen aufgezeigt und auch nicht bedachte Dinge zum Vorschein kommen. Außerdem haben Juniors in diesen Diskussionen schöne Aha-Erlebnisse.

Die gemeinsam gewählten Items des Sprint Backlogs werden nun in granulare Sub-Tasks, deren Bearbeitung maximal einen Tag dauern darf, herunter gebrochen und im Jira, einer Planungs-Software, dokumentiert. Diese Sub-Tasks bilden tatsächliche und vor allem (aber nicht nur) technische To Do’s ab.

Ist das Sprint Planning abgeschlossen, startet der Sprint und die Sub-Tasks der einzelnen Items im Sprint Backlog werden sukzessive vom Development Team umgesetzt.

Als Scrum Master moderiere ich das Sprint-Planning. Ggf. identifiziere ich Unklarheiten und versuche diese mit gezielten Fragen zu beseitigen. Außerdem muss das Team von Zeit zur Zeit „gechallenged“ werden, um zu prüfen, wie die Velocity ggf. gesteigert werden kann. Ich muss auch das Team auf ein potentielles „übercommitment“ hinweisen, wenn z.B. Urlaube oder Feiertage anstehen.

Im nächsten Post: Daily – Täglich stattfindene Meetings innerhalb eines Sprints.

 

 

 

* Die Velocity ist die Anzahl an Story Points, welche das (eingespielte) Team pro Sprint umsetzen kann. Sie wird einfach mit der Formel SUMME GESCHAFFTE STORY POINTS / ANZAHL SPRINTS errechnet.