Wie man ein Scrum Sprint Planning Meeting durchführt

Ein gut geführtes Sprint Planning Meeting stellt das Team auf einen produktiven Sprint ein. Folge diesem Schritt-für-Schritt-Moderationsleitfaden, um Sessions durchzuführen, die fokussiert, schnell und realistisch sind.

Planning Poker für Schätzung starten Zurück zu den Leitfäden

Vor dem Meeting: Checkliste zur Vorbereitung

Den oberen Teil des Backlogs verfeinern — die wichtigsten Einträge sollten klar, geschätzt und klein genug sein, um in einen Sprint zu passen.
Kapazität bestätigen — geplanten Urlaub, Feiertage und Support-Rotationen notieren. Die Kapazität als verfügbare Developer-Tage oder Story Points ausdrücken.
Den vorherigen Sprint überprüfen — Erkenntnisse aus Retrospektive und Review nutzen, um zu verstehen, was in diesem Sprint realistisch ist.
Einen Entwurf des Sprint-Ziels vorbereiten — der Product Owner kommt gewöhnlich mit einem Vorschlag; das Team verfeinert ihn gemeinsam.

Schritt-für-Schritt-Moderationsleitfaden

Mit dem Sprint-Ziel beginnen (5–10 Min)
Der Product Owner stellt das Ziel vor. Das Team diskutiert, ob es erreichbar, klar und wertvoll ist. Passt die Formulierung gemeinsam an, bis alle ausgerichtet sind.
Kapazität prüfen (5 Min)
Summiere die verfügbaren Arbeitstage pro Developer. Vergleiche sie mit der historischen Velocity des Teams in Story Points, um eine realistische Obergrenze für den Sprint festzulegen.
Backlog-Einträge auswählen (15–30 Min)
Ziehe Einträge vom oberen Ende des verfeinerten Backlogs, die das Sprint-Ziel unterstützen und in die Kapazität passen. Nutze Story Points als leichtgewichtige Größenprüfung. Schätze Einträge schnell neu, wenn sie sich seit dem Refinement wesentlich verändert haben.
Planning Poker für unklare Schätzungen nutzen (10–20 Min)
Wenn das Team neu schätzen oder neue Einträge dimensionieren muss, nutze Planning Poker. Öffne eine kostenlose Online-Session, füge die Stories hinzu, stimmt gleichzeitig ab, besprecht Unterschiede und konvergiert — meist innerhalb von 2–3 Runden pro Story.
Stories in Aufgaben aufteilen (15–20 Min)
Developers identifizieren die Arbeit, die nötig ist, um die Definition of Done zu erfüllen. Das Erfassen von Aufgaben bringt versteckte Komplexität und Abhängigkeiten früh ans Licht.
Risiken und Abhängigkeiten identifizieren (5 Min)
Sprecht alles an, was die Lieferung blockieren könnte: fehlende Designs, Drittanbieter-APIs, externe Freigaben. Ergänzt explizite Aufgaben oder Spikes für jedes Risiko.
Commit und Abschluss (5 Min)
Das Team bestätigt Sprint Backlog und Sprint-Ziel. Der Scrum Master aktualisiert den Sprint im Projektmanagement-Tool und schließt das Meeting.

Moderationstipps

Die Timebox schützen — wenn eine Diskussion abdriftet, parke das Thema und mache weiter. Löst es in einem Follow-up oder während des Sprints.
Das Sprint-Ziel in den Mittelpunkt stellen — jeder ausgewählte Eintrag sollte ihm dienen.
Nicht zu 100 % der Kapazität committen — lasst 10–20 % für unerwartete Arbeit, Bugs und Support frei.
<strong>Remote-freundliche Tools verwenden</strong> — wenn euer Team verteilt arbeitet, teilt Bildschirme, nutzt ein virtuelles Board und führt Online-Planning-Poker aus, um gleichzeitig abzustimmen.
Wichtige Entscheidungen dokumentieren — notiert Sprint-Ziel, Kapazität und verschobene Einträge im Backlog-Tool, bevor alle gehen.

Häufige Anti-Patterns, die vermieden werden sollten

Mit einem unverfeinerten Backlog starten — führt zu langen Diskussionen, fehlendem Kontext und schlechten Schätzungen.
Das Sprint-Ziel überspringen — lässt das Team ohne Kompass zurück, wenn sich Prioritäten mitten im Sprint verschieben.
Zu viel committen — optimistische Planung, die die Kapazität ignoriert, führt zu gescheiterten Sprints und geringer Moral.
Schätzungs-Kaninchenlöcher — jede Story-Schätzung auf 5–10 Minuten zu begrenzen hält die Session in Bewegung.
Der Product Owner entscheidet, was das Team tun kann — Developers besitzen den Plan; der Product Owner besitzt das Ziel.

Die Rolle des Scrum Masters beim Sprint Planning

Der Scrum Master leitet Sprint Planning nicht im traditionellen Sinne eines Meeting-Vorsitzenden. Seine Rolle ist es, den Prozess zu moderieren.

Praktisch bereitet der Scrum Master vor, indem er bestätigt, dass Backlog-Einträge verfeinert und bereit sind, dass die Kapazität berechnet ist.

Vor dem Planning: mit dem Product Owner bestätigen, dass die Top-Backlog-Einträge bereit, geschätzt und nach Priorität geordnet sind.
Während des Plannings: jede Diskussion timebox-mäßig begrenzen, Planning-Poker-Runden verwalten, und sicherstellen, dass das Sprint Goal vereinbart ist, bevor die Elementauswahl beginnt.
Nach dem Planning: das Sprint Goal im Tracking-Tool erfassen, das Sprint Backlog mit Stakeholdern teilen.

Die Rolle des Product Owners beim Sprint Planning

Der Product Owner ist die Stimme des Geschäftswerts beim Sprint Planning. Ihre primäre Aufgabe ist das Sprint Goal vorzuschlagen, die Priorität und den Umfang der Backlog-Einträge zu klären.

Die effektivsten Product Owner kommen zum Sprint Planning nach einem Vorab-Planungsgespräch mit dem Scrum Master.

Sprint Goal vorschlagen: als Geschäftsergebnis formulieren, nicht als Feature-Liste.
Umfang klären, nicht Implementierung: erklären, wie Erfolg für jede Story aussieht, ohne zu verschreiben wie das Team sie baut.
Für die gesamte Planungssitzung verfügbar sein: Product Owner, die nach der Zielvorstellung gehen, lassen das Team unfähig, Umfangsfragen zu beantworten.

Sprint Planning für Remote-Teams effektiv durchführen

Remote-Sprint-Planning führt Herausforderungen ein, die ortsansässiges Planning organisch handhabt.

Remote-Teilnehmer engagiert halten

Kameras während der Abstimmung eingeschaltet: Planning-Poker-Diskussionsqualität verbessert sich erheblich, wenn Teilnehmer sich sehen können.
Round-Robin-Beiträge für Aufgabenzerlegung: im Aufgabenzerlegungsbereich jeden Teilnehmer bitten, eine Aufgabe für die aktuelle Story zu benennen.
Den Parkplatz sichtbar nutzen: eine gemeinsame, sichtbare Liste der Themen pflegen, die aufgetaucht sind, aber außerhalb des Planungsumfangs liegen.

Tools für Remote-Sprint-Planning

Online-Planning-Poker-Tool: für gleichzeitige, unverankerte Schätzung.
Virtuelles Whiteboard: für Aufgabenzerlegung und Abhängigkeitskartierung.
Videokonferenz mit persistentem Chat: Chatkanal während der gesamten Sitzung offen halten.

Sprint-Planning-Bereitschafts-Checkliste

Diese Checkliste vor jeder Sprint-Planning-Sitzung nutzen. Wenn mehr als zwei Einträge nicht abgehakt sind, Planning verschieben.

Das Product Backlog ist mit klaren Prioritäten für die Top-1,5×-Sprint-Kapazität an Stories geordnet.
Alle Kandidaten-Stories haben akzeptierte Akzeptanzkriterien und sind vom Product Owner abgesegnet.
Alle Kandidaten-Stories haben Story-Point-Schätzungen aus einer aktuellen Planning-Poker-Sitzung.
Teammitglied-Verfügbarkeit für den Sprint ist bestätigt.
Sprint-Kapazität ist berechnet und mit dem Scrum Master vereinbart.
Der Product Owner hat einen Entwurf des Sprint Goals bereit.

Sprint-Planning-Meeting-FAQ

Soll das Sprint-Planning-Meeting eine feste Agenda haben?

Ja — und es im Voraus zu veröffentlichen verbessert die Vorbereitungsqualität.

Was tun wir, wenn Sprint Planning die Zeit überschreitet?

Bei der Timebox aufhören, auch wenn der Plan unvollständig ist. Ein überschrittenes Planning-Meeting ist ein Symptom, keine Lösung.

Können wir nach dem Planning Stories zum Sprint hinzufügen?

Das Sprint Backlog gehört dem Entwicklungsteam und kann während des Sprints aktualisiert werden. Hinzufügen sollte ein Ausnahmefall sein.

Wie gehen wir mit einem neuen Teammitglied um, das nicht schätzen kann?

Vom ersten Tag an als vollwertigen Abstimmenden einbeziehen. Neue Teammitglieder stellen oft Fragen, die erfahrene Mitglieder nicht mehr stellen.

Führe dein nächstes Sprint Planning mit kostenlosem Online-Planning-Poker durch

Sprint Planning mit kostenlosem Online-Planning-Poker durchführen