Planning 1
Heute reden wir über das Planning 1. Der aktuelle Scrum Guide kennt nur das Planning und unterscheidet nicht mehr zwischen 1 und 2. Wir halten das dennoch für sinnvoll und teilen die Folge 
daher nach 1 und 2 auf. Es ist endlich mal wieder eine Folge, die sich gezielt an unsere Product Ownerinnen wendet.
Diese Folde auf Youtube: https://youtu.be/DBjavG2SUxY
Erstes Event im Sprint
Beim Planning handelt es sich um das erste Event in einem neuen Sprint.
Wir führen das Ritual durch, damit alle wissen, was in der nächsten Iteration für unser Produkt getan wird. Also beispielsweise, welche Features umgesetzt werden oder welche Anforderungen abgearbeitet werden.
Im klassischen Projekt gibt dies der Projektmanager oder der Chef vor. Du merkst hier schon die Ähnlichkeit eines Scrum Sprints zu einem Wasserfall, nur sehr viel kürzer.
Der eigentliche Unterschied liegt nun darin, dass hier eine Einigung mit dem Team passiert, statt einfach nur wild, vielleicht unrealistische, Vorgaben zu machen.
Du merkst hier vielleicht auch schon, dass das Planning 1 Event das Äquivalent zu einem klassischen Lastenheft sein könnte. Der Output ist nämlich ein priorisiertes Sprint Backlog. Dieses ist eine Liste (in Reihung) der Anforderungen für einen Zeitabschnitt. Eben wie ein Lastenheft.
Was wollen wir tun
Das Ergebnis des Planning 1 ist dabei das Commitment des Teams zu dem WAS wollen wir tun. Es klammert dabei zu dem Zeitpunkt aus, WIE wir das erreichen werden.
Im originären Lastenheft sollte dies auch so sein. Wir besprechen hier mit dem Team, vor allen den Entwicklerinnen, nicht wie sie die Dinge zu erledigen haben. Sie sind schließlich die Expertinnen.
Der Vorteil vom Planning 1 ist auch ganz eindeutig: Alle wissen nun, was es zu tun gibt und was im nächsten Sprint passiert
Eingangsgröße
Eingangsgröße des Planning 1 ist, dass die Product Ownerin ein priorisiertes und besprochenes Backlog mitbringt.
Es ist also dem Team bereits vorher bekannt und gut vorbereitet. So kann der Product Owner leicht dem Team vermitteln, was für den nächsten Sprint geplant ist.
Das erfordert natürlich Vorarbeit. Beispielsweise in Form eines Refinements.
Selbstorganisation
Im Agilen achten wir jetzt ja viel auf Selbstorganisation, wie passt das zusammen?
Die Entwicklerinnen ziehen sich die User Stories von oben in den Backlog und haben einen Dialog oder eine Verhandlung mit der Product Ownerin. Diese darf also nicht einfach so viel wie möglich hineingeben, sondern das Team sagt wann Schluss ist.
Natürlich kann man hier der Product Ownerin im Vorfeld helfen, dass sie nicht zu viel vorbereitet und damit Verschwendung erzeugt. Beispielsweise, wenn die Velocitiy des Teams bekannt ist, es einen Durchschnittswert, WiP-Limits oder Story Points gibt.
In diesem Dialog können wir mit der Product Ownerin darüber sprechen, warum vielleicht einige Dinge so nicht zu realisieren sind. Beispielsweise weil Anforderungen Abhängigkeiten miteinander haben. Diese müssen vielleicht nacheinander statt gleichzeitig umgesetzt werden. Durch den Dialog kann sich auch die Reihenfolge noch einmal ändern. Beispielsweise weil das Team nur zwei sehr große Anforderungen je Sprint schafft und dazu viele kleine nehmen kann. Dies könnte auch zu einem anderen Story Split führen.
Abwesenheiten
Im Regelfall reicht der Dialog über die Anwesenheiten im nächsten Sprint bereits aus. Eine genaue Berechnung mag Henry Schneider zwar lieber und gleichzeitig bringt diese eher geringen Mehrwert.
Planning 1 grob zusammengefasst
Der Product Owner kommt einem priorisiertem und vorbesprochenem Backlog ins Planning, man spricht darüber, das Team zieht sich die Anforderungen von oben weg in den Sprint. Erledigt.
Janina Kappelhoffs schnellstes Planning: 42 Sekunden
Am Anfang dauert das natürlich länger. Gerade die ersten Plannings brauchen bestimmt 1 bis 2 Stunden.
Wenn das Planning doch zu lange dauert, dann schaut noch einmal auf das Thema Refinement und Teamdynamiken
Sprint Goal
Dazu hör bitte noch einmal in unsere Sprint Goal Folge rein. Theoretisch könnte die Product Ownerin mit dem Goal in das Planning kommen und das Team zieht sich dann die dazugehörigen Stories. Das Commitment läuft dann nur zu dem Sprint Goal und nicht zu den konkreten Stories ab. Ein Abbruch des Sprints und Nachjustierung, was man vielleicht nicht macht, wäre dann nur nötig, wenn sich während des Sprints zeigen würde, dass das Goal nicht mehr erreichbar scheint. Wenn nur auf die Stories commitmet wird, dann würde ich dieses eher etwas variabler halten, damit das Team nicht in den Modus geht sich immer unter ihrer Leistung zu verpflichten.
Anwesenheiten
Wer ist beim Planning alles anwesend? Alle Teammitglieder, inklusive Product Ownerin und Scrum Masterin. Zusätzlich auch gern Stakeholder und Interessierte. Also wirklich alle. Es ist auch ein öffentliches Meeting.
Rollentausch
In der Weitere Rollen Folge haben wir beschrieben, dass es in vielen Teams auch noch Sonderrollen, wie Supporter oder Testmanager gibt. Diese Rollen sollten rollieren, damit das Wissen und auch die Tätigkeiten dazu im Team gut gestreut sind. Es bietet sich an diese Rollen im Planning auch neu zu verhandeln.
Get shit done,
Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern.
Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann buch uns 😉
In der Podcastfolge erwähnte Folgen zur Vertiefung:
- Scrum Guide
- Product Ownerinnen
- Sprint
- Team
- Backlog
- Refinements
- Agilen
- Selbstorganisation
- WiP-Limits
- Story Points
- Sprint Goal
- Weitere Rollen
Connecte dich gerne hier mit uns:
