Sprint Planning

Timebox des Sprint Planning:

2 Stunden/Sprintwoche. Maximal 8 Stunden bei einem 4-Wochen Sprint. Je besser die Anforderungen im Product Backlog Refinement verstanden wurden, desto kürzer kann das Sprint Planning sein.

‍

Teilnehmer im Sprint Planning:

• Product Owner
• Scrum Master
• Developer

Im Sprint Planning sind alle Rollen des Scrum Teams vertreten. Product Owner und Developer besprechen die Anforderungen für den nächsten Sprint, der Scrum Master unterstützt beratend und kann eine Empfehlung, basierend auf der Team-Performance der letzten Sprints, abgeben.

Für den dritten Teil des Sprint Planning können noch Experten eingeladen werden, um den Developern bei der Umsetzungsplanung zu helfen.

‍

Zweck des Sprint Planning:

Im Planning sollen sowohl das Sprintziel als auch der Sprintplan festgelegt werden. Das Sprintziel wird vom Product Owner vorgeschlagen, genauso wie die Items für das Sprint Backlog. Letztlich entscheiden aber die Developer, zu welchen Aufgaben sie sich für den Sprint committen. Und sie alleine entscheiden, wie sie diese Aufgaben angehen. Dazu stehen folgende drei Themen auf der Agenda:

1. Warum ist dieser Sprint wertvoll?
   ‍
2. Was kann in diesem Sprint bearbeitet werden?
   ‍
3. Wie werden die ausgewählten Anforderungen bearbeitet?
   

‍

Der Ablauf des Sprint Planning in der Praxis:

Der Product Owner hat das Sprint Planning vorbereitet. Er hat die am höchsten priorisierten Items im Product Backlog im Refinement mit den Developern besprochen, sodass diese geschätzt vorliegen und alle Scrum Team Mitglieder inhaltlich auf dem Stand sind nun diskutieren zu können, wie viele Items umgesetzt werden können. Außerdem kommt der Product Owner mit einem Vorschlag für das Sprintziel ins Planning. Er muss darlegen können, warum dieser Sprint wertvoll ist. Auch für die Items, die vom Product Backlog in den Sprint Backlog wandern hat er einen Vorschlag. Der Scrum Master kann bei der Vorbereitung unterstützen, indem er dem Product Owner eine Prognose der Menge an Product Backlog Items abgibt, die voraussichtlich vom Development Team im Sprint fertiggestellt werden können – die sogenannte Velocity.

Mit dieser Vorbereitung beginnt der Product Owner das Planning indem er dem Scrum Team das Sprintziel vorstellt. Auf Basis dessen und der Priorisierung der Product Backlog Items ziehen sich nun die Developer Items ins Sprint Backlog.

Im dritten Teil des Sprint Plannings besprechen die Developer, wie sie die Aufgaben technisch umsetzen. Dabei hilft alles, was sinnvoll erscheint: Mockups, Skizzen, Code, usw. Bei großen Sprint Backlog Items sollten die Entwickler außerdem Unteraufgaben formulieren, um die Komplexität der einzelnen Items zu reduzieren und parallel an diesen arbeiten zu können. Das Planning ist abgeschlossen, wenn das "Wie" für den Sprint Backlog mindestens für die ersten zwei Tage des Sprints klar formuliert ist. Falls neue kann durchaus sein, dass der Sprintplan erst im Laufe des Sprints weiter konkretisiert wird.

‍

8 Tipps für das Sprint Planning:

1. Im Sprint Planning landen nur Product Backlog Items, die bereits priorisiert und geschätzt sind! Sollten zwischen dem letzten Product Backlog Refinement und dem Planning allerdings wichtige Anforderungen hinzugekommen sein, spricht nichts gegen eine Refinement Session im Rahmen des Plannings.
   ‍
2. Der Product Owner bereitet den Termin gut vor, um die Effizienz des Meetings zu gewährleisten.
   ‍
3. Kommuniziert für die ersten zwei Teile des Plannings in der Sprache des Product Owners. Es geht um Nutzen und Funktionalitäten, nicht um technische Details!
   ‍
4. Frag als Scrum Master nicht, ob das Umsetzungsteam die Items schaffen kann sondern ob es sie schaffen will.
   ‍
5. Sollte im Planning auffallen, dass ein Sprint Backlog Item viel zu groß oder viel zu klein eingeschätzt wurde, sollte der Product Owner hinzugezogen werden, da sich dadurch die Anzahl der Items im Sprint oder sogar das Sprintziel ändern können.
   ‍
6. Die Arbeitsmenge eines Sprint Backlog Items bzw. einer Unteraufgabe (Task) sollte möglichst klein sein. Im Idealfall maximal acht Stunden Arbeit.
   ‍
7. Bei großen Aufgaben, die nicht sinnvoll teilbar sind, sollte immer ein zeitlicher Puffer eingerechnet werden. Bei einem Sprint mit 10 Tagen Dauer, empfehlen wir einen zeitlichen Puffer von mindestens zwei Tagen.
   ‍
8. Die Aufgaben werden nicht einzelnen Personen zugewiesen. Jedes Teammitglied zieht sich im Laufe des Sprints eigenverantwortlich Aufgaben.

‍

‍