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 Team sitzt gemeinsam mit Tablets und Laptops an einem Holztisch und zwei geben sich einen Handschlag genau über diesem Tisch - Planning 1 - Product Ownerin Du hast viel zu tun :-)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,

Janina & Henry


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 😉


Janinas Ultimativer OKR Guide


In der Podcastfolge erwähnte Folgen zur Vertiefung:


Connecte dich gerne hier mit uns:

LinkedIn

Instagram

YouTube

Facebook

Webseite

Facebook-Gruppe