24 Min.

116 Planning 1 - Product Ownerin, Du hast viel zu tun. :-‪)‬ Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Acade

    • Selbstverwirklichung

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 Reihenfolg...

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 Reihenfolg...

24 Min.