"Sprint Planning: Warum 4 Stunden oft 4 Stunden verschwendet sind"

Dezember 2025 9 Min. Lesezeit Fallstudie

Sprint Planning ist das Event, das die Richtung für alles Folgende vorgibt. Wenn es funktioniert, verlässt das Team den Raum mit Klarheit, Zuversicht und einem gemeinsamen Verständnis davon, was es erreichen will. Wenn es nicht funktioniert – und das ist die meiste Zeit – verlässt das Team vier Stunden später mit einer Aufgabenliste, einem diffusen Unbehagen und keiner wirklichen Einigkeit darüber, warum das alles überhaupt relevant ist.

---

Der Einstieg: Vier Stunden sind nicht das Problem

Die häufigste Beschwerde über Sprint Planning ist, dass es zu lange dauert. Teams mit zweiwöchigen Sprints sollen Sprint Planning auf maximal vier Stunden begrenzen. In der Praxis überschreitet es das häufig. Manchmal deutlich.

Aber hier ist, was ich nach zwanzig Jahren Teilnahme, Facilitation und Beobachtung von Sprint-Planning-Events gelernt habe: Die Dauer ist nicht das Problem. Vier Stunden effektives Sprint Planning sind nicht zu lang. Vier Stunden ineffektives Sprint Planning sind ein Symptom, keine Ursache. Die Ursachen liegen weiter vorne – im Backlog, in der Beziehung des Teams zum Product Owner, in der Toleranz der Organisation für Ambiguität und in dem, was zwischen den Sprints passiert – oder eben nicht passiert.

---

Die Realität: Warum Sprint Planning scheitert

Scheitermodus 1: Der nicht vorbereitete Backlog

Die mit Abstand häufigste Ursache für schmerzhaftes Sprint Planning ist das Erscheinen beim Event mit einem Backlog, der nicht verfeinert wurde. Stories sind vage. Akzeptanzkriterien fehlen oder sind mehrdeutig. Abhängigkeiten wurden nicht identifiziert. Das Team verbringt die ersten zwei Stunden des Sprint Plannings damit, die Arbeit zu leisten, die in Refinement-Sessions des vorherigen Sprints hätte erledigt werden sollen.

Der Scrum Guide schreibt Refinement nicht als formales Event vor – er beschreibt es als fortlaufende Aktivität, die nicht mehr als 10 % der Teamkapazität beansprucht. In der Praxis lassen viele Teams Refinement entweder ganz weg oder behandeln es als Pflichtübung statt als echte kollaborative Investition in Backlog-Qualität.

Das Ergebnis ist ein Sprint Planning, das sich wie eine Archäologie-Ausgrabung anfühlt. Das Team gräbt die Bedeutung von Stories aus, die vor Wochen von jemandem geschrieben wurden, der nicht mehr verfügbar ist, um sie zu erklären. Wenn das Planning abgeschlossen ist, wurde die halbe Zeit mit Klärung statt mit Planung verbracht.

Die Refinement-Faustregel: Wenn Sie diese drei Fragen nicht für jede Story auf Ihrer Sprint-Planning-Kandidatenliste beantworten können – welches Problem löst das, wer profitiert, und woran werden wir erkennen, dass es fertig ist – ist die Story nicht bereit für Sprint Planning. Stopp. Verfeinern. Nächste Woche planen mit einem vorbereiteten Backlog.

Scheitermodus 2: Das fehlende Sprint Goal

Sprint Planning hat laut Scrum Guide zwei Teile. Der erste Teil legt das Sprint Goal fest – das Warum dieses Sprints. Der zweite Teil bestimmt, wie die Arbeit erledigt wird. Bei den meisten Sprint-Planning-Events, die ich beobachtet habe, dauert der erste Teil ungefähr fünf Minuten und besteht darin, dass der Product Owner die obersten Items aus dem Backlog vorliest. Der zweite Teil dauert drei Stunden und fünfundfünfzig Minuten.

Ein Sprint ohne ein bedeutungsvolles Goal ist eine Aufgabensammlung mit einer Deadline. Das Team hat keinen Nordstern für Entscheidungen während des Sprints. Wenn mitten im Sprint eine neue Anforderung entsteht, gibt es keine prinzipielle Grundlage zu entscheiden, ob sie aufgenommen oder verschoben werden soll. Wenn das Team auf eine unerwartete technische Herausforderung stößt, gibt es kein gemeinsames Verständnis davon, was aus dem Scope genommen werden kann, um das Kernziel zu schützen.

Ein bedeutungsvolles Sprint Goal ist nicht “die Items im Sprint Backlog abschließen.” Es ist eine Ergebnisaussage: Was wird am Ende dieses Sprints wahr sein, was jetzt nicht wahr ist – und warum ist das wichtig?

Scheitermodus 3: Schätzungstheater

Planning Poker. T-Shirt-Größen. Fibonacci-Folgen. Die Schätzungszeremonie im Sprint Planning ist oft der längste und streitigste Teil des Events – und häufig der am wenigsten wertvolle.

Der Zweck von Schätzungen im Sprint Planning besteht darin, dem Team zu helfen einzuschätzen, ob die ausgewählte Arbeit in den Sprint passt. Das ist alles. Es ist ein Kapazitätscheck, kein Commitment-Mechanismus. Wenn Schätzungen zur Verhandlung werden – wenn der Product Owner hohe Schätzungen anficht, wenn Entwickler unter Druck stehen, niedrig zu schätzen, um produktiv zu erscheinen, wenn dieselbe Story dreimal neu geschätzt wird, weil niemand einig wird – hat sich die Zeremonie von ihrem Zweck losgelöst.

Die Schätzungsfalle: Wenn Ihre Sprint-Planning-Schätzungsdiskussionen konsequent länger dauern als die eigentliche Arbeit zum Verstehen braucht – schätzt Ihr Team für jemand anderen, nicht für sich selbst. Schätzungen, die dem Management-Reporting dienen statt der Team-Planung, sind Overhead, kein Wert.

Scheitermodus 4: Commitment ohne Kapazität

Der Sprint beginnt. Das Team hat sich verpflichtet, zwölf Story-Points Arbeit zu liefern. An Tag drei wird klar, dass zwei der Stories deutlich komplexer waren als geschätzt, eine dritte eine Abhängigkeit hat, die beim Planning nicht identifiziert wurde, und ein Entwickler mit Produktionsproblemen beschäftigt ist, die bei der Kapazitätsplanung nicht berücksichtigt wurden.

Das ist kein Pech. Das ist vorhersehbar. Sprint Planning, das keine realistische Kapazität berücksichtigt – für Meetings, für Support-Verpflichtungen, für die unvermeidlichen Überraschungen, die jeder Sprint enthält – produziert Commitments, die nie erreichbar waren. Das Team verbringt den Sprint damit, die Lücke zwischen Geplantem und Möglichem zu managen, statt sich auf die Wertlieferung zu konzentrieren.

---

Der Checksum: Was effektives Sprint Planning produziert

Ich habe Sprint Planning gut gemacht gesehen. Nicht oft – aber oft genug, um zu wissen, wie es aussieht. Hier ist, was effektives Sprint Planning von der Theaterversion unterscheidet.

Effektives Sprint Planning	Sprint-Planning-Theater
Beginnt mit einem klaren Sprint Goal, das jeder artikulieren kann	Beginnt damit, die obersten Backlog-Items vorzulesen
Stories sind verfeinert, mit klaren Akzeptanzkriterien	Stories werden während des Plannings geklärt, was Stunden kostet
Kapazität wird realistisch berechnet, inkl. aller Verpflichtungen	Kapazität setzt volle Verfügbarkeit aller Teammitglieder voraus
Schätzung ist ein Team-Werkzeug zum Kapazitätscheck	Schätzung ist eine Verhandlung mit dem Product Owner
Team verlässt das Meeting mit klarem Plan und gemeinsamem Verständnis	Team verlässt das Meeting mit einer Aufgabenliste und Einzelzuweisungen
Dauer: 90–120 Minuten für einen zweiwöchigen Sprint	Dauer: 4+ Stunden, regelmäßig über die Timebox hinaus

Die letzte Zeile ist es wert, betont zu werden. Effektives Sprint Planning für einen zweiwöchigen Sprint sollte 90 bis 120 Minuten dauern – nicht vier Stunden. Vier Stunden sind das, was es kostet, wenn der Backlog nicht verfeinert ist, das Sprint Goal nicht klar ist und das Team Discovery-Arbeit leistet, die vorher hätte stattfinden sollen.

“Sprint Planning ist nicht der Ort, an dem man herausfindet, was zu tun ist. Es ist der Ort, an dem man bestätigt, dass man versteht, was zu tun ist, und sich darauf einigt, wie man es tun wird. Wenn man im Sprint Planning erst herausfindet, was zu tun ist, hat man bereits zwei Stunden verloren.” Markus – agile-checksum.com

---

Praxisbeispiele

Das sechsstündige Sprint Planning

Ein Team, zu dessen Coaching ich hinzugezogen wurde, führte sechsstündige Sprint-Planning-Events für zweiwöchige Sprints durch. Die Sessions waren erschöpfend, streitlustig und endeten konsequent damit, dass das Team unklar war, wozu es sich verpflichtet hatte.

Die Ursachenanalyse dauerte ungefähr dreißig Minuten. Es gab keine Refinement-Sessions. Der Product Owner schrieb Stories am Tag vor dem Sprint Planning. Die Stories hatten keine Akzeptanzkriterien. Die ersten zwei Stunden jedes Sprint Plannings wurden damit verbracht, Stories zu lesen und den Product Owner zu fragen, was er damit meinte. In der dritten Stunde war jeder müde. In der vierten Stunde akzeptierte das Team Stories, die es nicht vollständig verstand, nur um das Meeting zu beenden. In der sechsten Stunde fasste der Scrum Master zusammen, was vereinbart worden war, weil verschiedene Teammitglieder unterschiedliche Erinnerungen an die Entscheidungen aus Stunde zwei und drei hatten.

Die Lösung war nicht kompliziert. Wir führten zwei einstündige Refinement-Sessions pro Sprint ein. Der Product Owner verpflichtete sich, Stories – mit Akzeptanzkriterien – achtundvierzig Stunden vor dem Sprint Planning bereit zu haben. Sprint Planning reduzierte sich innerhalb von zwei Sprints auf neunzig Minuten. Die Sprint-Lieferung des Teams verbesserte sich messbar innerhalb eines Monats. Das Problem war nie Sprint Planning gewesen. Es war alles gewesen, was vor Sprint Planning hätte stattfinden sollen.

Das Sprint Goal, das eine Liste war

Die Sprint Goals eines Produktteams sahen konsequent, über acht Sprints hinweg, so aus: “Das User-Authentication-Feature abschließen, die drei kritischen Bugs aus dem letzten Sprint beheben und die Payment-Integration beginnen.” Das ist kein Sprint Goal. Das ist eine Zusammenfassung des Sprint Backlogs.

Als ich das Team fragte, was es mitten im Sprint tun würde, wenn es zwischen dem Authentication-Feature und der Payment-Integration wählen müsste, konnte niemand antworten. Es gab keine prinzipielle Entscheidungsgrundlage, weil es kein Sprint Goal gab, das eine Priorität festgelegt hatte. Jedes Item im Backlog war gleich wichtig, weil das Sprint Goal nicht festgelegt hatte, was am wichtigsten war.

Wir verbrachten im nächsten Sprint Planning eine Stunde damit, nur am Sprint Goal zu arbeiten, bevor wir den Backlog anfassten. Das Team formulierte: “Am Ende dieses Sprints können Nutzer sicher ein Konto erstellen und sich einloggen, was uns ermöglicht, Beta-Tests mit unseren ersten zehn Kunden zu beginnen.” Alles andere im Sprint wurde anhand dieses Goals bewertet. Drei Items, die zuvor als unverzichtbar galten, wurden verschoben, weil sie dem Goal nicht dienten. Der Sprint war der fokussierteste des Teams in sechs Monaten.

---

Das Fazit: Das Goal vor der Arbeit planen

Sprint Planning scheitert, wenn es zu einer Arbeitszuteilungsübung statt zu einer Goal-Setting-und-Planungsübung wird. Die Reihenfolge ist entscheidend. Zuerst das Goal. Dann die Arbeit. Immer.

Wenn Sie Sprint Planning mit einem klaren Sprint Goal verlassen, das jedes Teammitglied auswendig artikulieren kann – haben Sie den wichtigsten Teil erfolgreich abgeschlossen. Alles andere ist Logistik. Wenn Sie Sprint Planning mit einem detaillierten Aufgabenplan, aber ohne gemeinsames Verständnis davon verlassen, warum es wichtig ist – haben Sie die Arbeit geplant und die Planung übersprungen.

Führen Sie den Checksum für Ihr letztes Sprint Planning durch:

1. Wie lange dauerte es, sich auf das Sprint Goal zu einigen? Wenn die Antwort “wir haben es nicht wirklich diskutiert” lautet – das ist Ihr Hauptproblem.
2. Wie viele Stories erforderten erhebliche Klärung während des Sprint Plannings, die im Refinement hätte erfolgen sollen?
3. Kann jedes Teammitglied jetzt, ohne nachzuschlagen, das aktuelle Sprint Goal nennen?

Wenn Sprint Planning konsequent schmerzhaft ist, sagt Ihnen der Schmerz etwas. Hören Sie hin – aber suchen Sie die Ursache weiter vorne. Das Planning-Event ist selten der Ort, an dem das Problem wohnt.

---

Im Artikel verwendete Glossarbegriffe

• Sprint Planning – Das Event, das den Sprint einleitet, bei dem das Team das Sprint Goal definiert und Backlog-Items auswählt.
• Sprint – Eine feste Timebox von 1–4 Wochen, in der ein Scrum-Team ein potenziell auslieferbares Increment liefert.
• Product Owner – Die Scrum-Verantwortlichkeit für die Maximierung des Produktwerts und die Verwaltung des Product Backlogs.
• Backlog – Eine geordnete Liste von Arbeitsitems, die alles repräsentiert, woran ein Team arbeiten könnte.
• Story Points – Eine relative Schätzungseinheit, die Aufwand, Komplexität und Unsicherheit widerspiegelt.
• Definition of Done – Die gemeinsame Vereinbarung, was “fertig” für ein Produktinkrement bedeutet.