Sprint Planning: Wie das Scrum-Event funktioniert
Viele Teams erleben Sprint Planning als eines von zwei Extremen: entweder als endloses Meeting, das drei Stunden dauert und trotzdem keine Klarheit bringt, oder als Ticketverschiebung in Jira, die man genauso gut per E-Mail hätte erledigen können. Beides hat mit dem eigentlichen Zweck von Sprint Planning nichts zu tun.
Sprint Planning: Das Wichtigste in Kürze
- Definition: Sprint Planning ist das erste Event eines jeden Sprints. Das gesamte Scrum Team plant gemeinsam, welchen Wert der Sprint liefern soll, welche Backlog-Items dafür ausgewählt werden und wie die Arbeit erledigt werden soll.
- Drei Fragen: Der Scrum Guide 2020 strukturiert Sprint Planning über drei Fragen: Warum (Sprint Goal), Was (ausgewählte Items), und Wie (Plan für die Umsetzung).
- Sprint Planning Dauer: Maximal acht Stunden für einen vierwöchigen Sprint, vier Stunden für einen zweiwöchigen, zwei Stunden für einen einwöchigen Sprint. Gut vorbereitete Teams brauchen oft deutlich weniger.
- Rollen: Product Owner, Scrum Team (Developers) und Scrum Master nehmen teil. Der PO bringt die Richtung, das Team entscheidet, was es realistisch liefern kann.
- Das Sprint Goal entscheidet: Ein Sprint ohne klares Sprint Goal ist nur eine Liste von Aufgaben. Das Ziel gibt den Sprints Sinn und Richtung.
- Vorbereitung zählt: Ein ungepflegtes Product Backlog macht jedes Sprint Planning Meeting zur Qual. Refinement vor dem Planning ist kein optionaler Schritt.
Was ist Sprint Planning?
Sprint Planning ist laut Scrum Guide 2020 das Event, das einen Sprint einleitet. Es ist kein Statusmeeting, kein Aufgabenvergabe-Meeting und keine Verlängerung des letzten Sprint-Retrospektive-Gesprächs. Es ist der Moment, in dem das Scrum Team entscheidet, wohin es die nächsten ein bis vier Wochen läuft und warum.
Der entscheidende Unterschied zu klassischer Projektplanung: Das Team zieht sich die Arbeit selbst aus dem Product Backlog (Pull-Prinzip). Der Product Owner schlägt Richtung und Prioritäten vor, aber was das Team tatsächlich in einem Sprint liefern kann, entscheidet das Team. Diese Selbstverpflichtung ist kein Detail, sie ist das Fundament der Verlässlichkeit in agiler Softwareentwicklung.
Welche drei Fragen beantwortet das Sprint Planning Meeting?
Eine weitverbreitete Darstellung aus älteren Scrum-Versionen sagt, Sprint Planning beantworte zwei Fragen: Was und Wie. Der Scrum Guide 2020 hat das weiterentwickelt. Heute stehen drei Fragen im Mittelpunkt:
Die "Warum"-Frage ist der inhaltliche Fortschritt gegenüber der alten Zweiteilung. Sie stellt sicher, dass der Sprint ein klares Ziel verfolgt. Ein Sprint Goal ist ein Satz, der beschreibt, welchen Mehrwert der Sprint für Nutzer oder das Produkt erzeugt.
Wie lange dauert ein Sprint Planning?
Der Scrum Guide legt eine Timebox fest, die sich an der Sprint-Länge orientiert:
- 1-Wochen-Sprint: max. 2 h
- 2-Wochen-Sprint: max. 4 h
- 4-Wochen-Sprint: max. 8 h
Das sind Obergrenzen, keine Pflichtdauer. Teams mit einem gut gepflegten Backlog, klarem Sprint Goal und eingespielter Zusammenarbeit kommen oft in der Hälfte der Zeit durch. Teams, die regelmässig die Timebox sprengen, haben in der Regel ein Backlog-Problem: Items sind zu gross, zu unklar oder zu wenig vorbereitet. Das eigentliche Sprint Planning Meeting leidet dann unter Arbeit, die ins Refinement gehört hätte.
Die 60-70%-Kapazitätsregel: Ein 2-Wochen-Sprint sind nicht 10 × 8 Stunden reine Entwicklungszeit. Daily Scrums, Refinement-Sessions, ungeplante Support-Anfragen und Meetings fressen realistisch 30 bis 40 Prozent der nominalen Kapazität. Wer das beim Sprint Planning ignoriert, plant systematisch zu voll.
Welche Rollen sind im Sprint Planning beteiligt?
Am Scrum Sprint Planning nehmen alle Mitglieder des Scrum Teams teil:
- Der Product Owner bringt ein priorisiertes, verständliches Backlog mit und erklärt, welches Sprint Goal er für den aktuellen Sprint vorschlägt und warum. Er stellt Business-Kontext bereit, beantwortet Fragen und ist Gesprächspartner für Scope-Entscheidungen. Aber: Er drückt dem Team keine Tickets auf.
- Die Developers wählen aus, welche Items sie für erreichbar halten, schätzen den Aufwand ab und planen im zweiten Teil des Meetings die konkrete Umsetzung. Sie tragen die Verantwortung für eine realistische Aussage darüber, was der Sprint liefert.
- Der Scrum Master stellt sicher, dass das Meeting stattfindet, in der Timebox bleibt und das Team produktiv arbeiten kann. Er ist Moderator und Coach, kein Protokollführer.
Stakeholder können eingeladen werden, wenn sie dem Team konkrete fachliche Fragen beantworten können. Sie entscheiden aber nicht, was das Team in den Sprint zieht.
Wie läuft ein Sprint Planning Meeting ab?
01
Sprint Goal gemeinsam formulieren
Der PO schlägt vor, warum der Sprint wertvoll ist. Das Team diskutiert und formuliert gemeinsam ein Sprint Goal, das alle mittragen. Dieser Satz muss präzise und sinnstiftend sein. Er ist kein Wunschzettel.
02
Kapazität prüfen
Das Team schaut realistisch auf die verfügbare Kapazität: Urlaube, Feiertage, bekannte Meetings, laufende Support-Verpflichtungen. Realistisch eingeplante Kapazität liegt oft bei 60 bis 70 Prozent der nominalen Zeit.
03
Backlog Items auswählen
Das Team zieht Items, die zum Sprint Goal passen und in der verfügbaren Kapazität realistisch abgeschlossen werden können. Grundlage sind Velocity aus vergangenen Sprints und die aktuelle Kapazität.
04
Umsetzungsplan erstellen (Wie-Teil)
Die Developers planen konkret, wie sie die ausgewählten Items angehen. Oft werden Items in Tasks heruntergebrochen. Der PO ist dabei meist nicht aktiv beteiligt, bleibt aber für Fragen erreichbar.
05
Sprint Backlog finalisieren und Sprint starten
Das Ergebnis des Sprint Plannings ist ein Sprint Backlog mit dem Sprint Goal, den ausgewählten Items und dem Umsetzungsplan. Der Sprint beginnt unmittelbar danach.
Was macht ein gutes Sprint Goal aus?
Das Sprint Goal ist das stärkste Werkzeug im Sprint Planning, und gleichzeitig das, was in der Praxis am häufigsten schlecht gemacht wird. Ein Sprint Goal ist kein Ticket-Titel und keine Aufzählung von Features. Es beschreibt in einem Satz, welchen Mehrwert der Sprint für Nutzer oder das Produkt bringt.
Der Unterschied in der Praxis:
Das schlechte Sprint Goal ist eine Ticketliste. Es gibt dem Sprint keine Richtung, keine Priorisierung und kein Kriterium dafür, ob der Sprint erfolgreich war. Das gute Sprint Goal beschreibt ein konkretes Nutzerproblem, das gelöst wird. Wenn sich der Umfang der Items während des Sprints ändert, gibt es trotzdem eine klare Entscheidungsgrundlage.
Ein hilfreicher Formulierungsansatz: Sprint Goals im Präsens schreiben, aus Nutzerperspektive. "Nutzer können X" statt "Wir bauen Y". Das macht den Wert greifbar.
Was sind die häufigsten Fehler im agilen Sprint Planning?
Die meisten Probleme im Sprint Planning entstehen nicht im Meeting selbst, sondern davor oder durch falsche Erwartungen an den Prozess.
Was muss vor dem Sprint Planning vorbereitet sein?
Der grösste Hebel für ein gutes Sprint Planning liegt ausserhalb des Meetings selbst. Ein Sprint Planning Meeting, das über die Timebox geht, hat fast immer ein Vorbereitungsproblem.
Checkliste: Sprint Planning Vorbereitung
- Product Backlog gepflegt: Prioritäten aktuell, Items priorisiert nach Wert und Abhängigkeiten
- Top-Items refiniert: Die Items, die für den Sprint in Frage kommen, haben klare Akzeptanzkriterien und sind auf Sprintgrösse heruntergebrochen
- Velocity bekannt: Das Team weiss, wie viel es in den letzten Sprints geleistet hat
- Kapazität erfasst: Urlaube, Feiertage und bekannte Abwesenheiten sind für den kommenden Sprint bekannt
- Sprint Goal-Vorschlag vorhanden: Der PO hat eine Richtung vorbereitet, auch wenn das finale Goal gemeinsam formuliert wird
- Letzte Retrospektive berücksichtigt: Erkenntnisse aus dem letzten Sprint fliessen in Prozess oder Backlog ein
Iterative Softwareentwicklung mit Axisbits
Axisbits entwickelt Softwareprojekte iterativ, mit strukturierten Sprints, klarer Kommunikation und einem Product Owner auf Kundenseite, der jederzeit Einblick in den Entwicklungsstand hat. Wir bringen Scrum-Erfahrung aus über 100 Projekten mit und passen die Prozesse an die Grösse und den Reifegrad des Vorhabens an.
- Sprint-basierte Entwicklung: Zweiwöchige Sprints mit klaren Sprint Goals, priorisierten Backlogs und regelmässigen Reviews, an denen du als Kunde aktiv beteiligt bist.
- Transparenter Fortschritt: Nach jedem Sprint siehst du funktionierende Software, kein Statusbericht.
- Flexibler Scope: Neue Anforderungen können zwischen Sprints eingebracht werden, ohne das gesamte Projekt neu zu planen.
- Einführung agiler Prozesse: Wenn dein Team gerade in Scrum einsteigt, begleiten wir den Aufbau strukturierter Planungs- und Review-Prozesse.
{{fs-btn-cta}}
Wir schaffen leistungsstarke Plattformen und Websites für Startups, Scale-Ups und KMUs, von Konzept bis Go-Live.
Wir entwickeln dein Produkt iterativ, mit strukturierten Sprints und klarem Projektfokus.
Sprint Planning: Häufige Fragen und Antworten
Sprint Planning ist ein formales Scrum-Event am Beginn eines Sprints, in dem das Team entscheidet, was es im kommenden Sprint liefert. Backlog Refinement ist eine fortlaufende Aktivität (kein formales Event), bei der Items für kommende Sprints vorbereitet, detailliert und geschätzt werden. Refinement ist die Vorarbeit, Sprint Planning die Entscheidung. Teams, die kein regelmässiges Refinement durchführen, erleben ihr Sprint Planning fast immer als langwierig und unproduktiv.
Der PO sollte für den ersten Teil des Meetings vollständig anwesend sein: Sprint Goal formulieren, Items vorstellen, Fragen beantworten. Im zweiten Teil, wenn das Team konkret plant wie die Items umgesetzt werden, ist der PO oft weniger aktiv beteiligt. Er sollte aber erreichbar bleiben, falls Klärungsbedarf entsteht. Ganz wegfallen darf er nicht: Sprint Planning ohne PO ist wie ein Briefing ohne den Auftraggeber.
Das ist deutlich besser als zu viele Items auszuwählen. Ein Team, das seinen Sprint-Scope vollständig abschliesst, kann in Absprache mit dem PO weitere Items aus dem Backlog ziehen. Ein Team, das systematisch zu voll plant, liefert regelmässig unfertige Arbeit und baut technische Schulden auf. Lieber einen konservativen Forecast und dann nachziehen, als regelmässig mehr versprechen als lieferbar ist.
Ungeplante Arbeit ist normal. Das Sprint Goal hilft dabei, Prioritäten zu setzen: Passt die neue Aufgabe zum Sprint Goal, kann das Team sie aufnehmen und entsprechend anderen Scope verhandeln. Passt sie nicht, kommt sie ins Backlog für den nächsten Sprint. Wenn ungeplante Arbeit den Sprint regelmässig sprengt, ist das ein Signal für das nächste Sprint Planning: Kapazitäts-Puffer einplanen und Support-Aufwand explizit berücksichtigen.
Nein, Story Points sind kein Bestandteil des Scrum Guides. Sie sind ein verbreitetes Werkzeug, das Teams nutzen, um relative Komplexität einzuschätzen und Velocity zu messen. Alternativ funktionieren T-Shirt-Grössen (S/M/L), Anzahl von Tagen oder auch nur die Einschätzung des Teams, ob ein Item in den Sprint passt oder nicht. Was zählt, ist ein gemeinsames Verständnis davon, was in der verfügbaren Kapazität realistisch abgeschlossen werden kann.
Weitere Artikel
Ein Web Framework ist ein Software-Gerüst für die Entwicklung von Webanwendungen. Es stellt Funktionen wie Routing, Authentifizierung, Datenverarbeitung, Fehlerbehandlung und Template-Rendering bereit. Durch das Web Framework müssen Entwickler wiederkehrende Aufgaben nicht jedes Mal neu programmieren. Das Framework definiert zudem Aufbau, Architektur und Lebenszyklus einer Anwendung und sorgt damit für hohe Konsistenz im Code
Du optimierst deine Website nach Bauchgefühl, aber die Conversion Rate bleibt hartnäckig niedrig? Das Problem: Du weisst nicht, was deine Besucher wirklich tun, wo sie klicken und wann sie abspringen. In diesem Artikel erfährst du, wie Website Heatmaps dir das Verhalten der User offenlegen und wie du mit farbkodierten Nutzer-Daten deine Conversion Rate messbar steigerst.
Ein neues Produkt von der Idee bis zur Marktreife zu bringen, ist anspruchsvoll. Eine Produkt-Roadmap kann dir dabei helfen, deine Vision zu strukturieren und mit Stakeholdern zu teilen. Sie macht alle Schritte für alle Beteiligten verständlich, von der ersten Skizze bis zur Auslieferung und begünstigt die Zusammenarbeit im Team. Parallel dazu schafft sie Vertrauen nach aussen und weckt Interesse bei potenziellen Kunden.