Sprint Planning ist die Besprechung, die ein Scrum-Team zu Beginn jedes Sprints abhält, um drei Fragen zu beantworten: Was liefert dieser Sprint (Sprint Goal), welche Einträge aus dem Backlog kommen rein (Sprint Backlog) und wie wird jeder umgesetzt (Aufgabenschnitt und Ansatz). Am Ende der Besprechung startet das Team mit einem klaren Sprint-Ziel und einer ausführbaren Aufgabenliste.
Die 30-Sekunden-Version
- Frequenz: einmal pro Sprint, fest am ersten Tag der Iteration;
- Dauer: Zwei-Wochen-Sprint → höchstens 2 Stunden; Ein-Wochen-Sprint → 1 Stunde;
- Teilnehmer: das ganze Scrum-Team — Entwickler, Product Owner, Scrum Master;
- Ergebnis: 1 Sprint Goal + 1 Sprint Backlog (in ausführbare Aufgaben aufgeteilt);
- Besteht-nicht-Test: Nach der Besprechung kann jedes Mitglied aus dem Gedächtnis sagen: „Das bauen wir diesen Sprint."
Wo das Sprint Planning im Zyklus sitzt
Sprint Planning (Tag 1)
↓
Daily Standup × 9 Tage
↓
Sprint Review (Demo) + Sprint Retrospective
↓
Nächstes Sprint Planning
Das Planning konsumiert die Ergebnisse des vorigen Schritts: den Product Backlog und die Verbesserungsaktionen der letzten Retrospective. Wie die beiden Meetings zusammenhängen: siehe Sprint-Retrospective-Leitfaden.
Vorbereitung vor dem Meeting (die Hälfte der Effizienz)
| Vorbereitung |
Verantwortlich |
Standard |
| Product Backlog sortiert |
Product Owner |
Die obersten Kandidaten sind klar genug — kein Erklären des Kontexts im Meeting nötig |
| Kandidaten verfeinert |
Product Owner + Dev-Team |
Die Top-1,5–2×-Kapazität an Einträgen ist geschnitten/geschätzt |
| Teamkapazität gerechnet |
Scrum Master |
Effektive Personentage nach Urlaub, Meetings und Bereitschaftsabzug |
| Übertrag aus dem letzten Sprint geklärt |
Dev-Team |
Unerledigte Einträge: zurück ins Backlog oder in diesen Sprint — vor dem Meeting entschieden |
| Definition of Done bereit |
Team |
Alle stimmen zu, was „fertig" bedeutet |
Ohne vorbereitetes Backlog wird das Planning zum Anforderungs-Klärungsmarathon — die häufigste Ursache für Zeitüberschreitung.
Agenda-Vorlage (2-Stunden-Beispiel für einen Zwei-Wochen-Sprint)
| Zeit |
Abschnitt |
Was passiert |
| 0:00–0:10 |
Ziel setzen |
PO schlägt das angestrebte Geschäftsergebnis vor; das Team verdichtet es zu einem Ein-Satz-Sprint Goal (z. B. „Admins können Reports exportieren") |
| 0:10–0:50 |
Einträge wählen |
Backlog der Reihe nach durchgehen: kommt der Eintrag rein? Kapazitätsabzug bis voll |
| 0:50–1:40 |
Aufgaben schneiden |
Pro gewähltem Eintrag Aufgaben à 0,5–1 Tag ausschneiden und den technischen Ansatz notieren; umstrittene technische Risiken sofort klären |
| 1:40–1:55 |
Risiken und Abhängigkeiten |
Externe Abhängigkeiten (Dritt-APIs, Designs, andere Teams), Bereitschaftsplan, Priorität bekannter Bugs |
| 1:55–2:00 |
Bestätigen und committen |
Sprint Goal und Eintragsliste wiederholen; alle bestätigen; die Startaufgaben für Tag eins benennen |
So berechnet man die drei Schlüsseleingaben
1. Kapazität
Effektive Personentage = Mitglieder × Arbeitstage − Urlaub − Meeting-Overhead − Bereitschaftsanpassung
Beispiel: 5-köpfiges Team, 10 Arbeitstage, insgesamt 3 Tage Urlaub, stehende Meetings kosten ca. 2 Personentage → 45 − 3 − 2 = 40 effektive Personentage.
2. Velocity
Durchschnitt oder Median der in den letzten 3–5 Sprints abgeschlossenen Story Points nehmen (der Median ist robuster gegen Ausreißer). Neues Team ohne Historie? Aus der Kapazität schätzen: 1 Personentag ≈ 1 Einheit wirksamer Arbeit, nach zwei Sprints auf Story Points umstellen. Missverständnisse über Velocity: siehe FAQ.
3. Schätzung
- Planning Poker ist das übliche Werkzeug: alle zeigen gleichzeitig eine Karte; Einträge mit großer Streuung werden besprochen und neu geschätzt;
- Granularitätsregel: Einträge über 8 Punkten werden vor der Sprint-Aufnahme gesplittet;
- Punkte schätzen relativen Aufwand, keine Stunden — niemals für individuelle Leistungsbeurteilungen verwenden.
Häufige Fehler und Korrekturen
| Fehler |
Folge |
Korrektur |
| Auf 100 % der Kapazität planen |
Null Puffer; ein überraschender Bug sprengt den Sprint |
Auf 80 % der Kapazität planen; Luft für unerwartete Defects und Kollaborations-Overhead lassen |
| PO erklärt Anforderungen nur mündlich im Meeting |
Das Meeting wird zur Anforderungs-Klärungssession |
Einträge vor dem Meeting verfeinern; im Meeting nur bestätigen, nicht unterrichten |
| Einträge wählen ohne sie zu schneiden |
Das „Wie" wird erst mitten im Sprint erdacht — zu spät |
Auf 0,5–1 Tag schneiden und den technischen Ansatz einmal durchdenken |
| Das Ziel ist eine Eintragsliste, kein Geschäftsergebnis |
Das Team haftet für „fertig", nicht für „nützlich" |
Das Sprint Goal muss ein geschäftsorientierter Ein-Satz sein |
| Bugs des letzten Sprints nie priorisiert |
Der neue Sprintplan kentert durch Überraschungsdefects |
Das Schicksal übertragener Bugs im Meeting festlegen (siehe nächster Abschnitt) |
Wohin mit Bugs im Sprint?
Ein oft übersprungener Teil des Plannings: welche Defects dieser Sprint bearbeitet und wessen Triage läuft. Im Meeting explizit festlegen:
Die Liste der übertragenen Bugs und ihr Schicksal (beheben / herabstufen / schließen);
Der Fluss für neue Bugs im Sprint: Triage → einstufen (P0 am selben Tag, P1 in diesen Sprint, P2 ins Backlog). Wie das geht: Bug-Triage-Leitfaden;
Ein einziger Eingang für Bug-Reports: Meldungen von Testern oder Nutzern müssen Reproduktionsschritte, Screenshots und Console-Fehler mitbringen — nicht im Gruppenchat verstreuen.
Punkt 3 ist der versteckte Hebel der Sprintgeschwindigkeit: Ein Report mit vollem Kontext lässt den Entwickler sofort loslegen, ohne Rückfragen. BugCapturers Ansatz dabei: Jede Einreichung hängt automatisch einen annotierten Screenshot/ein Recording, die URL, die Browserumgebung und Console-/Network-Fehler an (siehe Diagnosefunktion), und Berichte werden automatisch in einen Slack / Microsoft Teams-Kanal gepusht — im Planning werden Defects dann direkt anhand der Berichte im Kanal eingestuft, ohne Meeting-Zeit auf „was genau ist das Problem eigentlich?" zu verschwenden.
FAQ
F: Was ist ein Sprint-Planning-Meeting?
A: Das Planungsmeeting zu Beginn jedes Sprints in Scrum; es legt Umfang (was) und Ansatz (wie) fest und produziert Sprint Goal und Sprint Backlog.
F: Was ist Sprint Planning aus Sicht eines Business Analysten (BA)?
A: Der BA achtet auf Testbarkeit und Abnahmekriterien: ausgewählte Einträge tragen Akzeptanzbedingungen und klare Randfälle, und Stakeholder-Bedarfe werden in Backlog-Einträge übersetzt.
F: Wie lange darf das Planning dauern?
A: Faustregel: höchstens 1 Stunde pro Sprint-Woche — Ein-Wochen-Sprint 1 Stunde, Zwei-Wochen-Sprint 2. Überschreitungen deuten meist auf mangelnde Vorbereitung hin.
F: Wie macht ein Remote-Team das Planning?
A: Wie üblich Videocall plus geteiltes Board (Jira/Linear/Trello); beim Zuschnitt parallel auf einem Kollaborations-Whiteboard schreiben — ungefähr doppelt so schnell wie Einträge nacheinander vorzulesen.
F: Wir merken mitten im Sprint, dass der Plan zu klein war. Was nun?
A: Nichts nachschieben. Notieren und beim nächsten Planning bevorzugt aufnehmen; Dringendes läuft über die P0-Triage-Schiene.