Das Sprint Planning ist ein zeitgesteuertes Event, das zu Beginn das Sprints durchgeführt wird. Hier diskutieren und entscheiden das Team und der Product Owner über die Arbeit, die sie im kommenden Sprint abschließen wollen. Die Dauer des Meetings beträgt ca. 2 Stunden für jede Woche eines Sprints. Dies ist sehr abhängig von der Reife und Effizienz des Teams und des Product Owners und dem Umfang der Vorbereitung im Vorfeld. Dieses Treffen ist außerdem abhängig von einem guten Product Backlog und einem guten Verständnis dessen, was getan werden muss. In der Regel ist das Treffen in zwei Teile geteilt: Was & Wie.

Was?

Der Product Owner bringt eine Liste der priorisierten User Stories in das das Sprint Planning ein. Im Idealfall ist die Geschwindigkeit der Teams bekannt und transparent, so dass der Product Owner eine gute Vorstellung davon hat, wie viel Arbeit in einen Sprint passen sollte. Dies wird vom Team besprochen, sie brechen die Anwendergeschichten auf und vereinbaren dann die Arbeit, die im Sprint erledigt werden kann.

Wie?

Das Entwicklungsteam bespricht dann die vereinbarte Arbeit und wie man sie erledigt. Dabei geht es in der Regel darum, dass das Team die User Stories in Aufgaben zerlegt und die technischen Details durchsieht. Wenn ein Team ein regelmäßig Product Backlog Refinement durchführt, sollte das Team bereits eine Vorstellung davon haben, worum es in der User-Story geht.

Vorbereitung

Umfeld

Das Umfeld des Sprint Plannings ist wichtig. Das Team soll sich sicher fühlen. Es ist ok, im Moment nicht alles zu wissen. Bei Agile geht es um Anpassung, Reaktion und Lernen. Es sollte ein starkes Gefühl der Zusammenarbeit, Unterstützung, Neugier und Motivation vorhanden sein. Das Team sollte keine Angst haben, Fragen zu stellen oder sich zu äußern. Das Team muss so viel wie möglich verstehen, um sich darauf verlassen zu können, was es leisten kann. Es ist wichtig, dass das letzte Wort beim Team liegt, was umgesetzt werden kann, nicht beim Product Owner. Zuhören ist wichtig. Das Team sollte sich mit den Prioritäten und der Erklärung, die der Product Owner gibt beschäftigen. Es sollte aktiv zuhören und Fragen stellen.

Das Team muss den Product Owner respektieren und Vertrauen in seine Entscheidungen haben. Dies ist die Person, die ihre Arbeit priorisiert. Die Product Owner ist für das „Warum“ verantwortlich, also sollte sich das Team darauf konzentrieren. Der Product Owner ist für das Stakeholder-Management verantwortlich und repräsentiert die Anforderungen des Unternehmens. Das Team ist verantwortlich für das „Wie“. Es sollte auf beiden Seiten einen durchgängigen Respekt und eine klare Definition der Rollen, die jeder einzelne spielt, geben.

Voraussetzungen

Das Sprint Planning ist abhängig von der Arbeit, die tatsächlich vor dem Meeting geleistet wurde. Der Product Owner muss sicherstellen, dass jederzeit ein gesundes, gepflegtes und priorisiertes Product Backlog vorhanden ist. Die User Stories an der Spitze des Backlogs (die in den nächsten Sprint gehen sollten), sollten aufgeschlüsselt und klein genug sein, damit das Team diskutieren und planen kann, dies wird oft in der Backlog-Verfeinerung gemacht.

Eine gutes Sprint Planning ist zudem von einem motivierten Team abhängig. Es muss auch ein gutes Verhältnis zwischen dem Product Owner und dem Team bestehen.Das Team muss den Wert des Meetings und die Vorteile einer solchen Planung erkennen. Wenn es irgendwelche Zweifel oder Missverständnisse gibt, wird der Prozess scheitern.

Es sollte auch einen allgemeinen Konsens über Schätzungen der User Stories herrschen. Das ganze Team sollte sich auf eine Methode einigen, um die Konsistenz zu gewährleisten.

Ziele

Das Ergebnis des Sprint Plannings sollte ein Sprintziel sein. Dies geschieht in Form eines Sprint Backlogs; eine Liste von priorisierten Aufgaben, die das Team erledigt bzw. die „Definition of Done“ erfüllt. Wenn das Team den Sprint visuell und mental vollenden kann, dann ist das eine gute Motivation für den Einstieg in die Arbeit. Das Ziel ist es, am Ende des Treffens ein abgestimmes Sprint Backlog zu haben. Es ist jedoch völlig in Ordnung, die Arbeit während des Sprints neu zu bewerten. Während des Sprints können Dinge passieren, die außerhalb der Kontrolle liegen oder neu dazugelernt werden.

Das Sprint Planning Event

Es ist gut, eine gewisse Struktur in Form einer Agenda für das Sprint Planning zu haben. Es sollte für jedes Meeting einheitlich sein und wird dem Team helfen, in eine gute Routine zu kommen und das Beste aus dem Meeting herauszuholen.

Die Verwendung von Story Points, sind eine gute relative Methode zur Schätzung. Es gibt ein paar verschiedene Methoden, um mit Hilfe von Story Points zu schätzen, aber im Allgemeinen vergleichen diese Methoden Aufgaben und schätzen nach Komplexität, nicht nach Zeit. Sie betrachten die Größe der Aufgaben und versuchen, sie konsistent zu halten. Aufgaben, die nicht mehr als einen Tag in Anspruch nehmen, ermöglichen es Entwicklern, ihre Tage einfacher und effizienter zu planen. Kleinere Aufgaben geben daher eine bessere Vorstellung davon, was zu tun und reduzieren Engpässe.

Man sollte sich nicht zu sehr auf die geschätzten Werte festlegen. Schätzungen sind Annäherungen und keine gegebenen Verpflichtungen. Wenn alle mit der Schätzung und der damit verbundenen Arbeit zufrieden sind geht es weiter. Man sollte auch keine Aufgaben zuweisen. Solange es eine priorisiertes Backlog gibt, sollte Teammitglieder anderen helfen, sobald sie ihre eigenen Aufgaben erledigt haben. Wenn Aufgaben zugewiesen werden, bekommen dieselben Personen immer die gleiche Arbeit zugewiesen.

Abschluss

Das Sprint Planning ist ein zeitgesteuertes Event, also wird es rechtzeitig beendet. Auch wenn die Planung noch nicht abgeschlossen ist, ist es wichtig, die Arbeit tatsächlich zu beginnen. Mehr Planung wird die User Stories nicht vervollständigen. Es ist ok, nicht alle Details zu kennen, es fördert die Agilität! Das Ziel ist es, zu planen und zu verstehen, was getan werden muss. Ein Teil der Agilität ist die Fähigkeit zu experimentieren und zu innovieren, der Beginn der Arbeit gibt dem Team die Möglichkeit, dies zu tun.

Einen Überblick zur Serie Scrum Basics findest du hier: Scrum Basics: Alles auf einen Blick