Planning 2: Ablauf für Devs
Jedes Mal, wenn ich auf eine Person treffe, die sagt, sie würde in einem agilen Team nach Scrum arbeiten, stelle ich die Frage nach Planning 2. Meine persönliche Statistik (meine Umfragen sind natürlich nicht repräsentativ) zeigt, dass in 9 von 10 Fällen darauf verzichtet wird. Ich frage dann weiter nach dem "Warum" und auch hier ist in den meisten Fällen die Antwort, dass man gar nicht von der Existenz dieser Zeremonie weiß. Fairerweise muss man aber sagen, dass der offizielle Scrumguide in dieser Hinsicht etwas unspezifisch ist und nicht zwischen Planning 1 und Planning 2 unterscheidet. Es gibt eine gemeinsame und geteilte Timebox.
Ich möchte auch keine Diskussion auslösen, sondern nur ein hilfreiches Werkzeug beschreiben. Es dient als Impuls für euer nächstes Planning 2!
Was ist denn der Unterschied? #
Mein Team und ich haben es vom anfänglichen "Da schreiben wir nur die Tasks auf", zu einer ordentlichen Zeremonie gebracht. Aber wie unterscheidet man nun das erste vom zweitem Planning:
Im ersten Teil versammeln sich alle: Product Owner, Business Analyst, Entwickler, QA, Ui/UX, Fachexperten etc. Es wird das "Was" geklärt. Es geht hierbei um den Umfang. Welche Stories/Tickets werden in den nächsten Sprint genommen. Einvernehmlich. Es kommt zum Commitment.
Für das Planning 2 dienen diese Stories nun als Grundlage. Denn jetzt wird sich angeschaut, wie man konkret und technisch zur Lösung kommt. Alle Fragen sollten bereits im Refinement geklärt sein. Meine persönliche Erfahrung zeigt, dass dort aber meist immer dieselben Menschen sprechen und mitdenken :-) Ich gehöre nicht dazu.
Jetzt ist der richtige Zeitpunkt nochmal alles zu überdenken, Fragen zu stellen und dann gemeinsam einen Lösungsweg zu definieren. Aber wie geht man dafür am besten vor? Ich empfehle dafür einen Ablauf, den man immer wiederholen kann:
Wie läuft es ab? #
Vor jeder Runde sollte jemand bestimmt werden, der vorstellt. Diese Person stellt ihre Ergebnisse vor, schreibt mit, groupiert etc. Ein Scrum-Master kann gerne aushelfen. Zur besseren Abwicklung empfehle ich irgendein Board (virtuell oder analog), Stift und Zettel.
1. Verstehen #
Das Board wird geteilt und das erste Ticket geöffnet. Zunächst beginnt man mit dem Verstehen. Jeder Teilnehmer liest für sich die Anforderungen und versucht zu verstehen worum es geht. Offene Fragen werden beantwortet, die Anforderungen ggf. geschärft und/oder Akzeptanzkriterien nachgetragen. Am Ende haben alle "nahezu" dasselbe Verständnis worum es geht.
2. Planen #
Im nächsten Schritt wird eine Timebox vereinbart. 3-5 Minuten vielleicht, je nach Größe und Umfang des Tickets. Jeder überlegt für sich, wie man die Story in sinnvolle kleine Aufgaben zerteilen kann und schreibt diese für sich auf.
Beispiel #
Als Beispielstory nehmen wir ein Formular. Es soll ein neues Eingabefeld für das Alter hinzugefügt werden.
An der Stelle kommt häufig von unerfahrenen Kollegen die Aussage, dass man nur eine Aufgabe zu bewältigen hat: das Machen. Aber wenn man kurz darüber nachdenkt, fallen noch einige weitere Aufgaben auf. Ich empfehle immer, die Aufgaben so zu schneiden, dass man sie theoretisch parallel mit mehreren Menschen umsetzen kann:
Man muss man eine neues Feld in der UI anlegen, das Datenmodell erweitern, die Anbindung an das Backend schreiben, ggf. die Datenbank erweitern, Tests schreiben usw.
Damit haben wir eine gute Grundlage für den nächsten Schritt.
3. Diskutieren #
Die gesammelten Punkte werden nun vom gewählten Präsentator vorgestellt. Dieser wechselt nach jeder Story, damit jeder mal an die Reihe kommt. Er stellt vor und erklärt seine gesammelten Punkte. Im Anschluss können weitere Punkte der übrigen Teilnehmer gesammelt, diskutiert werden, Abhängigkeiten geklärt und eine Reihenfolge definiert werden. Häufig freut man sich, wenn man auf dieselben Punkte gekommen ist. Umso mehr freut man sich, wenn noch weitere Punkte auffallen, an die man gar nicht gedacht hat.
4. Einigung #
Im letzten Punkt sollten sich alle einig sein, dass man einen Weg durch die Story gefunden hat. Wenn nicht, geht man einen Schritt zurück und diskutiert nochmal. Ziel ist es, dass alle denselben Weg der Entwicklung einschlagen werden. Natürlich ist das nicht immer der Fall. Man kann aber den Plan in jedem Daily anpassen. Aber niemanden startet mehr kopflos, um nach einigen Tagen zu merken, dass man sich verrannt hat. Jetzt könnte man noch die gesammelten Aufgaben in Sub-Tasks niederschreiben und mit der nächsten Story starten. Alternativ schreiben wir manchmal alle Subtasks am Schluss auf.
Fazit #
Mit dieser Methode zwingt man sich, den aktuellen Sprint, auf den man sich commited hat, nochmal en détail anzuschauen und zu überdenken. Jeder ist gefragt. So kommen auch die ruhigeren Mitglieder des Teams dazu, etwas zu sagen. Am Ende haben alle einen und denselben Plan vom Sprint und es sollte keine Rolle mehr spielen, wer sich welche Story nimmt. Es herrscht Einigung und es gibt einen Plan. Besonders unerfahrene und chaotische Kollegen ;-) werden abgeholt und eingefangen. Das kann die Retrospektive extrem verkürzen.
Mit der Zeit wird diese Zeremonie auch kürzer. Meinem Team und mir hat diese Methode viel Zeit, Diskussion und Nerven gespart.
Ihr habt Fragen oder Anregungen? Schreibt mir bei Twitter oder bei LinkedIn.
Tausend Dank fürs Lesen!
Kuba