Beiträge

So führen Sie Sprint-Planning-Meetings durch, die wirklich funktionieren

Sprint Planning ist die Scrum-Zeremonie, die jeden Sprint einleitet. Das Team entscheidet, was gebaut wird, warum es wichtig ist und grob, wie es umgesetzt werden soll. Wenn es funktioniert, verlassen alle den Raum mit einem gemeinsamen Verständnis. Wenn nicht, folgen auf zwei Stunden Verwirrung zwei Wochen Chaos. Die meisten Teams führen Sprint Planning durch (laut Scrum Alliance etwa 86 %), aber viele behandeln es als Backlog-Vorlesung statt als echtes Planungsgespräch. So machen Sie es richtig.

Was Sprint Planning tatsächlich hervorbringt

Das Ergebnis des Sprint Plannings ist das Sprint Backlog, das aus drei Teilen besteht:

• Ein Sprint Goal, eine kurze Aussage darüber, warum dieser Sprint wichtig ist
• Die ausgewählten Backlog-Elemente, zu deren Fertigstellung sich das Team verpflichtet
• Ein Umsetzungsplan, wie das Team diese Elemente in ein funktionierendes Inkrement umwandeln will

Das Sprint Goal ist der Teil, den die meisten Teams überspringen, und gleichzeitig der wichtigste. Ohne dieses wird der Sprint zu einer losen Sammlung zusammenhangloser Aufgaben ohne klare Richtung.

Wer im Raum sein sollte

Das gesamte Scrum Team nimmt teil:

Rolle	Aufgabe im Sprint Planning
Product Owner	Stellt priorisierte Backlog-Elemente vor, schlägt das Sprint Goal vor, verhandelt den Umfang
Scrum Master	Moderiert das Meeting, überwacht die Timebox, beseitigt Hindernisse
Entwickler	Wählen Arbeit aus, zu der sie sich verpflichten können, planen die Umsetzung, zerlegen Stories in Aufgaben

Fachexperten oder Stakeholder können eingeladen werden, wenn ihr Input benötigt wird, aber sie sind Gäste, keine Entscheidungsträger. Ein häufiges Anti-Pattern: Nur ein oder zwei Teammitglieder sollen die Entwickler „vertreten". Wenn die Personen, die die Arbeit erledigen, nicht am Planungsgespräch beteiligt sind, halten die Zusagen, die ihnen übergeben werden, selten stand.

Die Meeting-Struktur

Das Meeting hat einen natürlichen Ablauf von der Zielsetzung bis zur Aufgabenplanung.

1. Sprint Goal festlegen

   Der Product Owner schlägt vor, warum dieser Sprint wichtig ist und welchen Mehrwert er liefern soll. Das Team arbeitet gemeinsam daran, dies zu einem klaren Sprint Goal zu schärfen. Wenn Sie einen Ausgangspunkt brauchen, probieren Sie einen Sprint-Goal-Generator. Beginnen Sie hier, nicht mit dem Backlog. Das Ziel gibt allem anderen eine Richtung.

2. Kapazität prüfen

   Bevor Arbeit ausgewählt wird, prüfen Sie die tatsächliche Verfügbarkeit. Wer ist im Urlaub? Wer hat Bereitschaftsdienst? Ein zuverlässiger Ansatz: Bilden Sie den Durchschnitt der Velocity der letzten drei Sprints mit einem Sprint-Velocity-Rechner und passen Sie ihn an bekannte Kapazitätsänderungen an.

3. Backlog-Elemente auswählen

   Der Product Owner geht die Elemente mit höchster Priorität durch (die bereits verfeinert und geschätzt sein sollten). Entwickler wählen aus, was sie angesichts ihrer Kapazität und der Definition of Done zuversichtlich abschließen können. Dies ist eine Verhandlung, keine Anweisung von oben.

4. In Aufgaben zerlegen

   Für jedes ausgewählte Element zerlegen die Entwickler die Arbeit in kleinere Aufgaben, idealerweise in einem Tag oder weniger abschließbar. Hier treten versteckte Komplexität und Abhängigkeiten zutage, bevor sie zu Überraschungen mitten im Sprint werden.

5. Sprint Backlog bestätigen

   Das Team überblickt das Gesamtbild: Sprint Goal, ausgewählte Elemente, Umsetzungsplan. Jeder sollte den Raum verlassen und erklären können, worum es in diesem Sprint geht und woran er als Erstes arbeitet.

Wie lange sollte es dauern

Der Scrum Guide legt Höchstwerte fest, keine Zielwerte:

Sprint-Länge	Maximale Planungszeit
1 Woche	2 Stunden
2 Wochen	4 Stunden
3 Wochen	6 Stunden
4 Wochen	8 Stunden

In der Praxis schließen die meisten Teams mit 2-Wochen-Sprints das Planning in 60–90 Minuten ab, wenn das Backlog vorher gut verfeinert wurde. Wenn Sie regelmäßig die volle Timebox ausschöpfen, ist das ein Refinement-Problem, kein Planungsproblem.

Wo Schätzungen ins Spiel kommen

Hier machen viele Teams Fehler. Schätzungen sollten vor dem Sprint Planning stattfinden, während des Backlog Refinements, nicht zu Beginn des Meetings selbst. Mike Cohn, der Planning Poker entwickelt hat, nennt zwei gute Zeitpunkte für Schätzungen:

1. Nach Story-Writing-Workshops, wenn ein Paket von 20–50 neuen Elementen dimensioniert werden muss
2. Während regelmäßiger Refinement-Sitzungen, wenn Elemente im Laufe des Sprints geklärt werden

Und einen schlechten Zeitpunkt: zu Beginn des Sprint Plannings. Dann ist es zu spät, damit der Product Owner Prioritäten basierend auf neuen Schätzungen anpassen kann, und Entwickler, die gedanklich bereits in den Umsetzungsmodus wechseln, tun sich mit relativer Größenschätzung auf hoher Ebene schwer. Wenn die obersten Backlog-Elemente bereits geschätzt beim Sprint Planning ankommen, wird das Meeting zu einer Auswahlübung („Wie viel dieser geschätzten Arbeit passt in unsere Kapazität?") statt zu einer Schätzungsdebatte. Das ist der Unterschied zwischen einer 90-Minuten-Sitzung und einer 3-Stunden-Sitzung. Wenn Ihr Team Planning Poker zur Schätzung nutzt, führen Sie diese Sitzungen während des Refinements durch. Tools wie Kollabe unterstützen asynchrone Schätzung, damit Teams in ihrer eigenen Zeit schätzen können, ohne die gesamte Gruppe zu blockieren.

Fehler, die Sprint Planning entgleisen lassen

Schlechte Backlog-Vorbereitung. Mit vagen, unverfeinerten Stories in das Planning zu gehen, ist die häufigste Ursache für lange, frustrierende Meetings. Wenn Akzeptanzkriterien vor dem Meeting nicht klar sind, werden sie während des Meetings nicht klarer. Kein Sprint Goal. Ohne ein Ziel gibt es keine Möglichkeit, Abwägungsentscheidungen zu treffen, wenn der Umfang eng wird. Sie enden mit einer zusammenhanglosen Aufgabenliste statt einem kohärenten Sprint. Übercommitment. Wenn Sie regelmäßig 30–40 % unerledigte Arbeit in den nächsten Sprint verschieben, nehmen Sie mehr an, als das Team liefern kann. Die meisten Teams verlieren 15–25 % ihres Sprints durch ungeplante Arbeit, Meetings und Overhead. Kalkulieren Sie das ein. Das „Wie" überspringen. Stories auszuwählen, ohne die Umsetzung zu besprechen, bedeutet, dass Überraschungen mitten im Sprint auftauchen. Schon fünf Minuten über den Ansatz verhindern die meisten davon. Als Status-Meeting behandeln. Sprint Planning ist vorwärtsgerichtet. Wenn Sie Zeit mit Updates über den letzten Sprint verbringen, gehört das in das Sprint Review oder die Retrospektive.

Sprint Planning im Laufe der Zeit verbessern

Wenn Sie eine Sache verbessern, dann das Backlog Refinement. Der Scrum Guide empfiehlt, 5–10 % der gesamten Sprint-Stunden für Refinement aufzuwenden. Wenn Stories mit klaren Akzeptanzkriterien, bekannten Abhängigkeiten und vorhandenen Schätzungen beim Planning ankommen, läuft das Meeting praktisch von selbst. Darüber hinaus:

• Teilen Sie Kandidaten-Elemente 1–2 Tage vorher, damit Entwickler vorab über Lösungsansätze nachdenken können
• Beginnen Sie mit dem Sprint Goal, nicht mit dem Backlog. Es schafft Fokus und erleichtert Umfangsentscheidungen
• Lassen Sie die Entwickler das „Wie" bestimmen. Der Product Owner verhandelt, was gebaut wird, die Entwickler entscheiden, wie
• Reservieren Sie Kapazität für technische Schulden. Erfahrene Teams planen bis zu 20 % ihres Sprints für Bugs und Refactoring ein
• Beziehen Sie Retrospektiven-Maßnahmen ein. Wenn das Team im letzten Sprint vereinbart hat, etwas zu ändern, sollte es im Plan dieses Sprints auftauchen

Sprint Planning im größeren Zusammenhang

Sprint Planning ist eine Zeremonie in einem Zyklus und funktioniert am besten, wenn die anderen Zeremonien ihren Teil beitragen. Retrospektiven decken Prozessverbesserungen auf, die in den Plan des nächsten Sprints einfließen. Sprint Reviews liefern Stakeholder-Feedback, das Prioritäten formt. Daily Standups passen den Plan an, wenn sich Dinge ändern. Und Backlog Refinement bereitet das Rohmaterial vor, das Sprint Planning effizient macht. Wenn der Rest des Zyklus gesund ist, wird Sprint Planning zum kürzesten Meeting, nicht zum längsten.