Sprint Planning

Timebox des Planning:

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

Teilnehmer im Planning:

• Product Owner
• Scrum Master
• Development Team

Im ersten Teil des Sprint Planning sind alle Rollen des Scrum Teams vertreten. Product Owner und Development Team 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.

Zweck des Sprint Planning:

Im Planning 1 dreht sich alles um das "Was?". Welche Product Backlog Items kommen in den nächsten Sprint? Der Product Owner und das Development Team beschließen gemeinsam sowohl die Menge der Product Backlog Items für das Sprint Backlog, als auch das übergeordnete Sprintziel.

Der Ablauf des Sprint Planning in der Praxis:

Der Product Owner kommt vorbereitet in das Planning 1. Sowohl das anvisierte Ziel, als auch die geplanten Product Backlog Items sollen soweit vorbereitet sein, dass sie dem Development Team vorgestellt werden können. 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. Ist das "Was?" im Planning 1 besprochen, geht es im Planning 2 weiter mit dem "Wie?", also der technischen Umsetzung.

4 Tipps für das Sprint Planning:

1. Im Sprint Planning 1 landen nur Product Backlog Items, die bereits priorisiert und geschätzt sind! Sollten zwischen dem letzten Product Backlog Refinement Meeting 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 in der Sprache des Product Owners. Es geht um Nutzen und Funktionalitäten, nicht um technische Details! (Dafür ist das Planning 2 da).
4. Frag als Scrum Master nicht, ob das Umsetzungsteam die Items schaffen kann sondern ob es sie schaffen will.

Timebox des zweiten Sprint Planning:

Da sich Planning 1 und Planning 2 die Timebox teilen, gilt auch im Planning 2: zwei Stunden/Sprintwoche. Maximal 8 Stunden bei einem 4-Wochen Sprint.

‍

Teilnehmer im zweiten Sprint Planning:

• Development Team
• Ggf. Experten

Das zweite Planning wird eigenverantwortlich durch das Development Team durchgeführt. Bei Bedarf können Experten hinzugezogen werden, die bei der Umsetzungsplanung unterstützen. Auch der Product Owner kann konsultiert werden, sollten Unklarheiten entstehen oder Unbedachtes auffallen.

‍

Zweck des weiten Plannings:

Im zweiten Planning dreht sich alles um das "Wie". Nachdem die Product Backlog Items für den Sprint im Planning 1 festgelegt wurden, erstellt das Development Team gemeinsam einen flexiblen Plan, um das Sprintziel zu erreichen.

‍

Der Ablauf des zweiten Sprint Plannings in der Praxis:

Nach dem Planning 1 können Scrum Master und Product Owner den Meetingraum verlassen, denn nun geht es an die fachliche Planung. Die Mitglieder des Development Teams nehmen sich ein Product Backlog Item nach dem anderen vor und besprechen die konkrete Umsetzung. Dabei hilft alles, was sinnvoll erscheint: Mockups, Skizzen, Code, usw. Bei großen Product Backlog Items sollten die Entwickler außerdem Unteraufgaben formulieren, um die Komplexität der einzelnen Product Backlog Items zu reduzieren und parallel an diesen arbeiten zu können. Das Planning 2 ist abgeschlossen, wenn das "Wie" aller Product Backlog Items für den Sprint klar ist.

‍

‍

‍

4 Tipps für das zweite Sprint Planning:

1. Sollte im zweiten Planning auffallen, dass ein Product 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.
2. Die Arbeitsmenge eines Product Backlog Items bzw. einer Unteraufgabe (Task) sollte möglichst klein sein. Im Idealfall maximal acht Stunden Arbeit.
3. 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.
4. Die Aufgaben werden nicht einzelnen Personen zugewiesen. Jedes Teammitglied zieht sich im Laufe des Sprints eigenverantwortlich Aufgaben.

‍

Der Unterschied zwischen Sprint Planning 1 und Sprint Planning 2:

Im ersten Teil, dem Sprint Planning 1, liegt der Fokus auf dem „Was?“. Hier besprechen der Product Owner und das Development Team, welche Product Backlog Items (PBIs) in den kommenden Sprint aufgenommen werden sollen. Gemeinsam wird das Sprintziel definiert und die Menge der PBIs für das Sprint Backlog festgelegt. Der Scrum Master unterstützt beratend und gibt Empfehlungen basierend auf der bisherigen Team-Performance.

Im Gegensatz dazu konzentriert sich das Sprint Planning 2 auf das „Wie?“. Das Development Team plant eigenverantwortlich die technische Umsetzung der im ersten Teil festgelegten PBIs. Es werden konkrete Aufgaben definiert, mögliche Unteraufgaben erstellt und ein detaillierter Umsetzungsplan entwickelt. Bei Bedarf können Experten oder der Product Owner hinzugezogen werden, falls während der Detailplanung Fragen oder Unklarheiten auftreten. Während Planning 1 strategische Entscheidungen trifft, liegt der Schwerpunkt von Planning 2 auf der praktischen und technischen Umsetzung der Aufgaben im Sprint.

‍

Die häufigsten Fehler im Sprint Planning:

Ein häufiger Fehler ist die unzureichende Vorbereitung des Product Owners, der entweder mit unklaren oder übermäßig detaillierten Product Backlog Items (PBIs) in die Planung geht. Dies kann zu Missverständnissen und ineffizienter Nutzung der Meetingzeit führen.

Ein weiteres Problem ist das Fehlen eines klaren Sprintziels. Ohne ein eindeutiges Ziel fehlt dem Team die Orientierung, was die Priorisierung und Fokussierung während des Sprints erschwert. Zudem kann eine übermäßige Detailplanung während des Meetings kontraproduktiv sein. Der Versuch, jede Aufgabe im Voraus exakt zu definieren, führt oft zu Zeitverschwendung und mindert die Flexibilität des Teams, auf Veränderungen zu reagieren. Schließlich beeinträchtigt eine unzureichende Kommunikation innerhalb des Teams die Effektivität des Sprint Plannings. Wenn Teammitglieder ihre Bedenken oder Ideen nicht offen teilen, können wichtige Aspekte übersehen werden, was die Qualität der Planung und letztlich die des Produkts mindert. Um diese Fehler zu vermeiden, ist es wichtig, dass der Product Owner die PBIs angemessen vorbereitet, ein klares Sprintziel definiert wird, die Planung nicht in übermäßigen Details erstickt und eine offene Kommunikationskultur im Team gefördert wird.

‍

Die Ausbildung zum Scrum Master & Product Owner

Die beiden Begründer von Scrum bieten jeweils ein weltweit anerkanntes Zertifikat an. Nach dem Besuch eines Workshops zur Prüfungsvorbereitung steht dann die Online Prüfung zum Professional Scrum Master (Scrum.org) oder Certified Scrum Master (Scrum Alliance) an. Einen Vergleich der beiden Zertifikate haben wir in diesem? Blogbeitrag für dich zusammengefasst. HelloAgile bietet einen dreitägigen Zertifizierungsworkshop zum Professional Scrum Master & Product Owner an, der an sich an der Scrum-Praxis orientiert. Auch nach dem Workshop bieten wir all unseren Teilnehmern Hilfestellung bei allen Fragen rund um den richtigen Einsatz von Scrum an.

‍