Was zwischen Planning I und Planning II passiert

Die meisten Teams, denen ich bisher begegnet bin, teilen das Sprint Planning in einen ersten und einen zweiten Teil. Im ersten Teil stellt der Product Owner die Items aus dem Backlog vor, die im den nächsten Sprint entwickelt werden sollen. Das Team hat die Möglichkeit fachliche Fragen zu stellen und der Product Owner antwortet. Im Planning II zerlegt das Team die Stories in Tasks. So weit, so gut.

Die fachlichen Fragen des Teams hat der Product Owner im Planning I beantwortet. Aber was ist mit den technischen Fragen? Über diese stolpern die meisten Teams während des Planning II. Oft passiert es dann, dass sich einzelne Teammitglieder vor ihren Computer setzen und in den Tiefen des Quellcodes abtauchen – nur, um dann für den gesamten Rest des Plannings nicht mehr aufzutauchen. Das ist ärgerlich für den Rest des Teams.

Manche Teams lösen das über ein Pre-Planning der Stories im Sprint davor. Allerdings das Pre-Planning zu verschwendeter Zeit führen, nämlich dann, wenn Stories doch nicht in den nächsten Sprint kommen.

Um diese Situationen zu vermeiden, habe ich mit meinen Teams eine Phase zwischen Planning I und Planning II eingeführt.

Das ideale Planning II ist eine Mischung aus Architektur-Diskussion und Test-Design. Es wird geklärt, wie die Funktionalitäten im Code realisiert werden sollen, welche Klassen und Packages dafür benötigt werden, an welchen Stellen Refactorings notwendig sind, welche Sonderfälle mit Unit Tests abgedeckt werden müssen, welche Funktionalitäten durch Integrationstests abgesichert sein sollen – und wie diese Aufgaben am besten zerlegt werden könnten. Woher aber kommt das Wissen über all diese Dinge?
Sicher, die Erfahrung des Teams spielt dabei eine große Rolle, sowohl die allgemeine Entwicklungs-Erfahrung wie auch die spezifische Erfahrung im Projekt. In großen Projekten, an denen mehrere Teams arbeiten, kommt es aber regelmäßig vor, dass man an Stellen weiterarbeiten oder auf Code aufbauen muss, mit denen man vorher nichts zu tun hatte.
Um die daraus entstehende Unsicherheit zu reduzieren, habe ich vor einiger Zeit versucht, zwischen Planning I und Planning II Pomodoro-Sessions einzuführen. Das ist relativ einfach, erfordert aber eine hohe Disziplin.

Nach dem Planning I sollte dem Team klar sein, zu welchen Stories es noch Klärungsbedarf gibt. Im Idealfall ist das keine, aber das passiert eher selten. Diese Stories schreibt man nun auf Post-Its und klebt sie an die Wand.
Das Team kommt zusammen und jeweils zwei bis drei Leute suchen sich eine Story heraus, zu der sie offene Fragen klären wollen. Das können Recherchen zu den beteiligten Komponenten sein, Betrachtungen der bereits existierenden Testfälle, kurzum alles was das Team benötigt, um Sicherheit für das Planning II zu gewinnen.
Wenn sich Gruppen von zwei bis drei Leuten gebildet haben und jede Gruppe eine Story hat, geht das Timeboxing los. Jede Timebox ist – klassisches Pomodoro – 30 Minuten lang. Zunächst werden in 5 Minuten die Fragen besprochen, aufgeschrieben und priorisiert. Das können durchaus mehr sein, als die Gruppe Mitglieder hat. Auf keinen Fall sollten es weniger sein. Zuletzt wird festgelegt, wer welche Frage bearbeitet.
Dann beginnt die zweite Timebox, die 10 Minuten dauert. Hier sitzt entweder jeder an seinem Rechner oder man arbeitet Paarweise. Ziel ist es nun, die Frage aus der ersten Timebox zu beantworten. Das geht am besten mit Stift und Papier.
In der dritten Timebox, die ebenfalls 10 Minuten dauert, tauschen die Gruppenmitglieder ihre Erkenntnisse aus. Dabei können zwei Ergebnisse entstehen. Entweder sind die Unsicherheiten eliminiert, die Story kann also ins Planning II gehen oder aber es besteht noch Bedarf. Dann ist es Zeit für ein zweites Pomodoro.
Aber erst, nachdem man 5 Minuten Pause gemacht hat.

Die Pomodoro-Sessions laufen, so lange es noch Unsicherheiten gibt. Die kurzen Timeboxen erlauben ein sehr konzentriertes und fokussiertes Arbeiten. Daher ist in der Regel, nach zwei bis drei Pomodoro-Sessions, genügend Sicherheit für das Planning II gewonnen. Sollte eine Story dennoch zu Unsicherheit im Team führen, kann man für diese Story einen Spike im kommenden Sprint einplanen und die Story einen Sprint weiterschieben.

Auf die Dauer des gesamten Plannings wirkt sich die Pomodoro-Methode nicht negativ aus. Die Teams benötigen meist maximal eine Stunde für das Planning I. Die Pomodoro-Timeboxen benötigen bei drei Sessions maximal 90 Minuten. Das Planning II wiederum dauert dann noch einmal ein bis zwei Stunden. Insgesamt ist das Team also drei bis fünf Stunden mit Planning beschäftigt – und hat ein gutes Gefühl dabei.

Mehr zu Pomodoro gibt es auf pomodorotechnique.com, der Website von Francesco Cirillo.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.