Was ist Sprint Planning in Scrum?

Sprint Planning ist das Scrum-Ereignis, das jeden Sprint einleitet. Das Team einigt sich auf ein Sprint-Ziel, wählt Backlog-Einträge zur Lieferung aus und erstellt einen Plan, an den alle glauben — alles innerhalb einer festen Timebox.

Definition von Sprint Planning

Sprint Planning ist eines der fünf Scrum-Ereignisse, die im Scrum Guide beschrieben werden. Es findet zu Beginn jedes Sprints statt und bezieht das gesamte Scrum-Team ein: die Developers, den Product Owner und den Scrum Master.

Der Zweck ist, drei Fragen zu beantworten:

  1. Warum ist dieser Sprint wertvoll? → Sprint-Ziel
  2. Was kann in diesem Sprint erledigt werden? → Auswahl des Sprint Backlogs
  3. Wie wird die Arbeit erledigt? → Aufgabenaufschlüsselung und Plan

Wie lange dauert Sprint Planning?

Der Scrum Guide begrenzt Sprint Planning auf maximal 8 Stunden für einen einmonatigen Sprint. Bei zweiwöchigen Sprints — dem häufigsten Rhythmus — zielen die meisten Teams auf 2–4 Stunden.

Wenn euer Sprint Planning regelmäßig überzieht, sind die häufigsten Ursachen:

  • Backlog-Einträge wurden nicht vorher verfeinert oder geschätzt.
  • Es fehlen Akzeptanzkriterien, die im Meeting geklärt werden müssen.
  • Stories sind zu groß und müssen spontan aufgeteilt werden.

Regelmäßiges Backlog Refinement — einschließlich Planning Poker für Story-Point-Schätzung — verkürzt Sprint Planning deutlich.

Wer nimmt an Sprint Planning teil?

  • Developers — verantwortlich für den Plan und das Commitment zur Arbeit.
  • Product Owner — klärt Prioritäten, Akzeptanzkriterien und das Sprint-Ziel.
  • Scrum Master — moderiert, beseitigt Hindernisse und schützt die Timebox.
  • Stakeholder (optional) — können auf Einladung teilnehmen, um Kontext zu geben.

Eingaben für Sprint Planning

  • Verfeinerter Produkt-Backlog — sortiert, geschätzt und zur Auswahl bereit.
  • Teamkapazität — Verfügbarkeit nach Feiertagen, Support-Pflichten und Urlaub.
  • Historische Velocity — durchschnittlich abgeschlossene Story Points pro Sprint.
  • Definition of Done des Teams — gemeinsames Verständnis davon, was „fertig“ bedeutet.

Das Sprint-Ziel

Das Sprint-Ziel ist eine einzelne, prägnante Aussage, die vermittelt, warum der Sprint wertvoll ist. Es gibt dem Team Richtung, wenn während des Sprints Zielkonflikte entstehen, und hilft Stakeholdern zu verstehen, worauf das Team hinarbeitet.

Ein gut formuliertes Sprint-Ziel beginnt mit dem Ergebnis (Wert), nicht mit einer Aufgabenliste. Beispiel: „Kunden ermöglichen, ihr Passwort ohne Kontakt zum Support zurückzusetzen.“

Schätzung während Sprint Planning

Teams, die Story Points und Planning Poker für das Backlog Refinement nutzen, gehen mit bereits geschätzten Einträgen in Sprint Planning. Die Hauptarbeit beim Sizing besteht dann darin, diese Schätzungen zu bestätigen oder anzupassen, wenn man mehr über Umfang und Abhängigkeiten erfährt.

Wenn ihr direkt im Meeting schätzen müsst, haltet es leichtgewichtig: Nutzt euer Online-Planning-Poker-Tool, timeboxt die Diskussion und verschiebt Unbekanntes in einen Spike.

Was Sprint Planning hervorbringt

  • Sprint-Ziel — das gemeinsame „Warum“ des Sprints.
  • Sprint Backlog — die ausgewählten Einträge und der Plan zu ihrer Lieferung.
  • Erste Aufgabenaufschlüsselung — Aufgaben, die von den Developers identifiziert werden, um mit der Arbeit zu beginnen.

Sprint Planning im Scrum-Framework

Sprint Planning existiert nicht isoliert. Es ist eines von fünf formalen Scrum-Events, positioniert am Anfang jedes Sprints.

Wo Sprint Planning im Scrum-Zyklus passt

  • Der Scrum-Zyklus ist eine Schleife, keine Linie. Die Sprint Retrospektive eines Sprints fließt direkt in die Planung des nächsten ein.
  • Backlog Refinement, obwohl kein formales Scrum-Event, ist der kritische Vorbereitungsschritt, der Sprint Planning funktionsfähig macht.
  • Der Daily Scrum verbindet Sprint Planning mit der Sprint-Ausführung. Der in Sprint Planning erstellte Plan wird täglich aktualisiert.

Wie Sprint Planning sich von anderen Scrum-Events unterscheidet

  • vs. Sprint Review: Sprint Planning schaut vorwärts (was werden wir bauen?); Sprint Review schaut zurück.
  • vs. Sprint Retrospektive: Sprint Planning konzentriert sich auf das Produkt; Sprint Retrospektive konzentriert sich auf den Prozess des Teams.

Die drei Fragen, die jedes Sprint Planning beantworten muss

Der Scrum Guide rahmt Sprint Planning um drei Fragen. Das sind keine optionalen Diskussionsthemen — sie sind die Mindest-Outputs.

Warum ist dieser Sprint wertvoll?

Das ist die Sprint-Goal-Frage. Der Product Owner schlägt ein Ziel vor, das den höchsten aktuellen Geschäftswert widerspiegelt.

Was kann in diesem Sprint getan werden?

Das ist die Kapazitätsfrage. Das Team überprüft das Product Backlog, wählt Einträge aus, die das Sprint Goal unterstützen.

Wie wird die gewählte Arbeit erledigt?

Das ist die Aufgabenzerlegungs-Frage. Das Sprint Backlog wächst von einer Story-Liste zu einem handlungsfähigen Tagesplan.

Teams überspringen manchmal die dritte Frage, weil sie sich wie Überplanung anfühlt. Das Ergebnis ist, dass Stories am ersten Tag ins Stocken geraten.

Häufige Sprint-Planning-Herausforderungen und wie man sie löst

Selbst erfahrene Scrum-Teams stoßen auf wiederkehrende Planungsprobleme.

Wenn das Team konsequent übercommittet

Übercommitment ist der häufigste Sprint-Planning-Misserfolg. Es hat typischerweise drei Ursachen: unrealistische Kapazitätsberechnungen, sozialer Druck und fehlendes Velocity-Datum.

Der Fix ist strukturell: einen Kapazitätspuffer vorschreiben (für 70–80 % der theoretischen Kapazität planen).

Wenn Stories ohne Bereitschaft zum Planning kommen

Stories ohne Akzeptanzkriterien, Schätzungen oder Klarheit über Abhängigkeiten verschwenden Planning-Zeit.

Eine Definition of Ready implementieren: eine Story muss Akzeptanzkriterien, eine Schätzung und keine ungelösten externen Abhängigkeiten haben.

Eine dritte häufige Herausforderung — der Product Owner ändert Prioritäten mitten im Planning — wird am besten durch Vereinbarung vor dem Meeting gelöst.

Sprint-Planning-FAQ

Was ist der Unterschied zwischen einem Sprint und einer Iteration?

Im Scrum sind Sprints der formale Begriff für eine fest-dauer-Iteration (typischerweise 1–4 Wochen).

Können wir die Sprint-Länge zwischen Sprints ändern?

Technisch ja, aber häufige Änderungen untergraben Velocity-Daten und Team-Rhythmus.

Was passiert, wenn das Team kein Sprint Goal vereinbaren kann?

Ein Sprint ohne Sprint Goal ist nicht mit dem Scrum-Framework konform.

Wie gehen wir mit dringender Arbeit um, die nach dem Sprint Planning ankommt?

Dringende Arbeit sollte zum Product Owner gebracht werden, der entscheidet, ob sie bestehenden Sprint-Umfang verdrängt.

How long should sprint planning last?

Sprint planning is timeboxed to a maximum of eight hours for a one-month sprint, and proportionally less for shorter sprints — roughly two hours per week of sprint length. The single biggest factor in finishing on time is a well-refined Product Backlog, so treat refinement as a continuous activity rather than something to cram into the meeting.

Who attends sprint planning?

The entire Scrum Team attends: the Product Owner, the Scrum Master, and the Developers. The Product Owner brings priorities and a Sprint Goal candidate, the Developers decide how much they can commit to and how they will build it, and the Scrum Master facilitates and keeps the meeting inside its timebox. The team may invite others for advice, but they do not run the meeting.

What three questions does sprint planning answer?

Sprint planning answers three things: why the sprint is valuable (the Sprint Goal), what can be done this sprint (the selected backlog items), and how the chosen work will get done (the plan for delivering it). Covering all three is what turns a list of tickets into a committed, achievable sprint.

What is the difference between sprint planning and backlog refinement?

Backlog refinement is the ongoing work of clarifying, splitting, and estimating upcoming items so they are ready before the sprint. Sprint planning is the single event where the team selects from that ready backlog and commits to a Sprint Goal. If planning routinely runs long, it is usually a sign refinement is being skipped.

Schätze dein nächstes Sprint Backlog mit kostenlosem Online-Planning-Poker

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