Sprint-Planung: Wie man ein effektives Sprint-Planning-Meeting durchführt

Sprint-Planung ist das Event, das einen Backlog voller Ideen in einen klaren, verbindlichen Plan verwandelt, den das Team tatsächlich umsetzen kann. Gut durchgeführt dauert es unter zwei Stunden und lässt das Team energiegeladen zurück. Schlecht durchgeführt zieht es sich bis in den Nachmittag und produziert eine Liste, der niemand vertraut.

Was ist Sprint-Planung?

Sprint-Planung ist ein zeitlich begrenztes Event in Scrum, bei dem sich Entwicklungsteam, Product Owner und Scrum Master zu Beginn jedes Sprints treffen, um zu entscheiden, welche Arbeit sie abschließen und wie sie das tun werden. Das Meeting produziert zwei Ergebnisse: ein Sprint-Ziel (das "Warum") und einen Sprint Backlog (die spezifischen Einheiten, die das Team auswählt, um dieses Ziel zu erreichen).

Sprint-Planung ist Teil des umfassenderen agilen Methodik-Frameworks. Sprints sind kurze, festlänge Zyklen (typischerweise ein bis vier Wochen), die Teams einen regelmäßigen Rhythmus für die Lieferung von funktionierender Software oder fertigen Arbeitsinkrements geben. Sprint-Planung ist, wie jeder Zyklus mit Absicht statt mit Annahmen beginnt.

Der Scrum Guide definiert zwei Kernfragen für jede Sprint-Planungssitzung: Was kann aus dem Product Backlog während dieses Sprints geliefert werden, und wie wird die ausgewählte Arbeit erledigt? Diese zwei Fragen entsprechen direkt den zwei Teilen des Meetings, die die Scrum-Community oft "Teil 1: das Was" und "Teil 2: das Wie" nennt.

Ein gut durchgeführtes Sprint-Planning ist konkret beim Scope, ehrlich bei der Kapazität und geerdet in einem Sprint-Ziel, das dem Team für die nächsten zwei Wochen einen einzigen gemeinsamen Fokuspunkt gibt.

Key Facts

• Der Scrum Guide sieht für Sprint-Planung in einem einmonatigen Sprint bis zu 8 Stunden vor, proportional skaliert für kürzere Sprints (Scrum Guide, 2020).
• Teams mit einem klaren Sprint-Ziel liefern die vollständige Sprint-Verpflichtung 2,5-mal häufiger (State of Agile Report 17. Ausgabe, 2024).
• Sprint-Planung verbraucht bei effizienter Durchführung etwa 5 % der Arbeitsstunden eines 2-Wochen-Sprints (Scrum.org Community-Daten, 2024).

Warum Sprint-Planung wichtig ist

Ohne Sprint-Planung verfallen Teams in Ad-hoc-Priorisierung. Arbeit wird aufgenommen basierend darauf, wer am lautesten fragt, nicht was am wichtigsten ist. Sprint-Planung durchbricht dieses Muster, indem eine gemeinsame Verpflichtung vor Arbeitsbeginn geschaffen wird, nicht danach.

Die Vorteile zeigen sich messbar. Teams mit klaren Sprint-Zielen haben weniger Richtungsänderungen mitten im Sprint, weil alle bereits zugestimmt haben, wie "fertig" für diesen Zyklus aussieht. Kapazitätsplanung (bei der Sprint-Planung korrekt durchgeführt) verhindert, dass das Team sich überladet, was die häufigste Ursache für Sprint-Misserfolge ist. Und das Ritual selbst schafft psychologische Sicherheit: Wenn ein Team gemeinsam eine Verpflichtung eingeht, ist es eher bereit, Blocker früh anzusprechen, statt sie bis zum letzten Tag zu verstecken.

Sprint-Planung schafft auch eine direkte Verbindung zwischen der täglichen Arbeit und der Produkt-Roadmap. Jedes Sprint-Ziel sollte einem größeren strategischen Ziel entsprechen. Wenn Teams diese Verbindung explizit am Anfang jedes Sprints ausgesprochen sehen, fühlt sich die Arbeit weniger wie eine Aufgabenliste an und mehr wie Fortschritt.

Für Teams, die sich von der Wasserfall-Methodik wegbewegen, ist Sprint-Planung oft der deutlichste Beweis, dass agile Lieferung anders funktioniert. Statt eines Sechs-Monats-Plans, der von oben kommt, gestaltet das Team die nächsten zwei Wochen selbst, mit voller Transparenz über das, was es vereinbart.

Die zwei Teile der Sprint-Planung

Der Scrum Guide strukturiert Sprint-Planung in zwei verschiedene Gespräche. Die meisten gescheiterten Sprint-Planungs-Meetings scheitern, weil Teams direkt zu Teil 2 übergehen, bevor Teil 1 wirklich geklärt ist.

Teil 1: Was werden wir tun? (Sprint-Ziel und Einheitenauswahl)

Der Product Owner präsentiert die wichtigsten Einheiten aus dem priorisierten Product Backlog. Das Team stellt Fragen zu Scope, Akzeptanzkriterien und Abhängigkeiten. Gemeinsam formulieren sie ein Sprint-Ziel: eine einzige, prägnante Aussage, was dieser Sprint aus Stakeholder-Sicht erreichen soll. Sobald das Ziel feststeht, wählt das Team die Product Backlog Items (PBIs) aus, die das Ziel erreichen würden, wenn sie abgeschlossen werden.

Teil 1 ist abgeschlossen, wenn das Team sich auf das Sprint-Ziel geeinigt hat und eine Kandidatenliste von Einheiten vorliegt. Nicht weitermachen, bis diese zwei Ergebnisse vorliegen.

Teil 2: Wie werden wir es tun? (Aufgabenzerlegung und Kapazitätsprüfung)

Mit den ausgewählten Einheiten auf dem Tisch zerlegt das Team jede in konkrete Aufgaben (typischerweise je ein halber bis zwei Tage Aufwand). Hier findet die Kapazitätsplanung statt: Das Team prüft, ob die Aufgaben in die verfügbaren Sprint-Stunden oder Story Points angesichts der tatsächlichen Verfügbarkeit passen. Einheiten, die nicht passen, gehen zurück in den Backlog.

Teil 2 produziert einen Sprint Backlog: das Sprint-Ziel plus die ausgewählten Einheiten plus die Aufgabenzerlegung. Das ist der operative Plan des Teams für den nächsten Sprint.

Sprint-Planning-Agenda (das 2-Stunden-Meeting)

Die folgende Tabelle zeigt eine zweiStunden-Agenda für einen Zwei-Wochen-Sprint. Zeiten proportional skalieren für kürzere oder längere Sprints.

Wenn das Meeting für einen Zwei-Wochen-Sprint über zwei Stunden läuft, anhalten und diagnostizieren. Häufige Ursachen: Backlog-Einheiten wurden vor dem Meeting nicht verfeinert, das Sprint-Ziel wurde nicht vereinbart, bevor zur Einheitenauswahl übergegangen wurde, oder zu viele Einheiten sind unzureichend spezifiziert.

Schritt für Schritt: Sprint-Planning-Meeting durchführen

Schritt 1: Kapazität vor dem Meeting berechnen

Bevor jemand Platz nimmt, berechnet der Scrum Master (oder wer auch immer moderiert) die verfügbare Kapazität des Teams für den Sprint. Das ist nicht "jeder arbeitet 10 Tage, also haben wir 10 Tage Kapazität pro Person." Es berücksichtigt Meetings, Urlaub, Bereitschaftsdienst und den Fokus-Faktor (den realistischen Prozentsatz der Zeit, der für Sprint-Arbeit vs. Unterbrechungen aufgewendet wird).

Eine einfache Kapazitätstabelle (im nächsten Abschnitt ausführlich behandelt) dauert fünf Minuten zu erstellen und spart vierzig Minuten mitten im Meeting.

Schritt 2: Backlog-Einheiten gegen die Definition of Ready prüfen

Bevor Einheiten für einen Sprint ausgewählt werden können, sollten sie die Definition of Ready (DoR) erfüllen. Die DoR ist eine team-definierte Checkliste, die ein Backlog-Element vor dem Sprint-Planning erfüllen muss. Typische Kriterien umfassen:

• Akzeptanzkriterien sind schriftlich und vom Team verstanden
• Abhängigkeiten sind identifiziert und entsperrt (oder das Risiko ist bekannt)
• Die Einheit ist geschätzt (Story Points oder T-Shirt-Größen)
• Keine einzelne Einheit umspannt mehr als die halbe Sprint-Länge

Einheiten, die die DoR nicht erfüllen, werden im Backlog markiert und zur Verfeinerung an den Product Owner zurückgegeben. Nicht in den Sprint ziehen.

Schritt 3: Sprint-Ziel gemeinsam formulieren

Der Product Owner schlägt ein Sprint-Ziel-Entwurf vor. Das Team verfeinert die Formulierung, bis sie widerspiegelt, was das Team tatsächlich baut, nicht nur, was das Unternehmen sehen möchte. Ein gutes Sprint-Ziel ist:

• Spezifisch genug, um falsifizierbar zu sein (am Sprint-Ende kann geprüft werden, ob es erreicht wurde)
• Flexibel genug, um einige PBIs auszutauschen, wenn Unerwartetes auftaucht
• Einthematisch (ein Ziel pro Sprint; mehrere Ziele schwächen den Fokus)

Beispiel für ein schwaches Sprint-Ziel: "Den Onboarding-Flow verbessern." Beispiel für ein starkes Sprint-Ziel: "Ein neuer Nutzer kann sein Konto aktivieren und seine erste wichtige Aktion abschließen, ohne den Support zu kontaktieren."

Schritt 4: Product Backlog Items auswählen

Mit dem vereinbarten Sprint-Ziel wählt das Team PBIs vom oberen Teil des Backlogs aus, die das Ziel am besten unterstützen. Das ist ein Gespräch, kein Download: Das Team stellt Fragen, verhandelt den Scope und teilt manchmal große Einheiten in kleinere auf, um in den Sprint zu passen.

Velocity (die durchschnittlichen Story Points des Teams pro Sprint über die letzten drei bis fünf Sprints) als Obergrenze für die Auswahl verwenden. Nicht mehr als Velocity auswählen. Wenn das Team durchschnittlich 32 Punkte pro Sprint abschließt, nicht 45 laden.

Schritt 5: Einheiten in Aufgaben zerlegen

Für jedes ausgewählte PBI listet das Team die konkreten Aufgaben auf, die zur Erfüllung der Akzeptanzkriterien erforderlich sind. Aufgaben sollten klein genug sein, dass der Fortschritt täglich sichtbar ist (ca. 0,5 bis 2 Tage jeweils). Diese Zerlegung deckt auch versteckte Komplexität auf: Eine Story, die wie 3 Punkte aussah, offenbart manchmal fünf Aufgaben mit einem kombinierten Schätzwert, der deutlich höher ist.

Wenn die Aufgabenliste einer Story weit über die ursprüngliche Schätzung hinausgeht, kann das Team neu schätzen, die Story aufteilen oder sie in den Backlog zurückgeben. Besser, diese Entscheidung jetzt zu treffen als am achten Sprint-Tag.

Schritt 6: Verpflichtung eingehen und abschließen

Das Team führt eine abschließende Kapazitätsprüfung durch: Gesamter geschätzter Aufwand vs. verfügbare Sprint-Kapazität. Wenn es passt, verpflichtet sich das Team. Wenn nicht, kommen Einheiten heraus (niemals hinein). Der Scrum Master schreibt den Sprint Backlog auf und protokolliert offene Fragen oder Abhängigkeiten, die am ersten Tag nachverfolgt werden müssen.

Verpflichtung hier bedeutet keinen Vertrag. Es bedeutet, dass das Team ernsthaft glaubt, dass diese Einheiten angesichts des aktuellen Wissensstands erreichbar sind. Dieser Unterschied ist wichtig, besonders in Teams, die durch Überversprechen bereits verbrannt wurden.

Kapazitätsplanung: die Mathematik

Kapazitätsplanung ist einfache Arithmetik, aber es ist leicht, falsch zu rechnen, wenn der Fokus-Faktor übersprungen wird.

Die Formel:

Verfügbare Kapazität (Punkte) = Verfügbare Tage x Fokus-Faktor x Punkte pro Tag

Der Fokus-Faktor gibt den realistischen Anteil jedes Arbeitstages wieder, der für Sprint-Arbeit aufgewendet wird (im Gegensatz zu Meetings, E-Mails, Support-Tickets und anderen Unterbrechungen). Für die meisten Teams liegt er zwischen 0,6 und 0,8. Neue Teams oder Teams mit hoher Support-Last tendieren zum unteren Ende.

Beispiel-Kapazitätstabelle für einen 2-Wochen-Sprint (10 Arbeitstage):

In diesem Beispiel liegt die Velocity-Obergrenze des Teams bei 53 Story Points. Wenn die historische Velocity des Teams bei 40 Punkten liegt, 40 als praktische Obergrenze verwenden: Velocity berücksichtigt Arbeit, die hängen bleibt oder unerwartet komplex wird, auch wenn Personen verfügbar sind.

Nie rohe Arbeitstage als Proxy für Kapazität verwenden. Ein Team aus fünf Entwicklern, die je 10 Tage arbeiten, hat keine 50 Sprint-Kapazitätstage. Der Fokus-Faktor existiert, um Planung ehrlich zu machen.

Sprint-Planning-Beispiele nach Teamtyp

Der Projektstrukturplan-Ansatz eignet sich gut, um große Sprint-Einheiten in aufgabennahe Komponenten zu zerlegen, besonders für Entwicklungs- und Designteams, bei denen Stories mehrere technische Unteraufgaben haben.

Häufige Sprint-Planning-Fehler (und Lösungen)

Best Practices für Sprint-Planning

• Zeitbox einhalten. Ein Zwei-Wochen-Sprint erhält ein zweistündiges Planning-Meeting. Wenn das Meeting überläuft, signalisiert das ein Processproblem (unzureichend verfeinerter Backlog, unklares Ziel), kein Arbeitslast-Problem.
• Backlog vor Sprint-Planning verfeinern. Die besten Sprint-Planning-Meetings fühlen sich fast zu einfach an, weil Einheiten bereits gut verstanden sind. Eine Mitte-Sprint-Verfeinerungssitzung durchführen, um die Top-10-15-Einheiten vorab zu verfeinern.
• Sprint-Ziel an die Wand schreiben (oder in einem gemeinsamen Dokument). Ein Ziel, das nur im Gedächtnis von jemandem ist, hört am dritten Tag auf, Entscheidungen zu leiten. An einem Ort platzieren, den das gesamte Team täglich sieht.
• Konsistente Schätzungsskala verwenden. Ob Story Points, T-Shirt-Größen oder Idealtage: eines wählen und über Sprints hinweg dabei bleiben, damit Velocity-Vergleiche aussagekräftig bleiben.
• Das gesamte Scrum-Team einbeziehen, sonst niemanden. Sprint-Planning ist für Product Owner, Scrum Master und Entwicklungsteam. Stakeholder, Manager und Führungskräfte nehmen nicht teil. Ihr Input kommt über die Backlog-Einheiten, die der Product Owner zum Meeting bringt.
• Neuen Workstreams mit dem Projektlebenszyklus als Orientierung beginnen. Für Teams, die ein völlig neues Produkt oder eine Initiative starten, hilft die Verankerung des ersten Sprint-Ziels im übergeordneten Projektlebenszyklus dem Team zu verstehen, wie dieser Sprint mit dem Lieferbogen zusammenhängt.
• In der Retrospektive auswerten. Wenn das Team Sprint-Ziele konsequent verfehlt, ist das ein Sprint-Planning-Problem. Die Retrospektive sollte Planungsgenauigkeit neben Lieferleistung prüfen.
• Über Scrum vs. Kanban-Abwägungen schulen. Teams, die beide Methoden kennen, treffen bessere Sprint-Planning-Entscheidungen, besonders wenn sie entscheiden, ob die Sprint-Struktur für ihren Arbeitstyp überhaupt geeignet ist.

Häufig gestellte Fragen

Wie lang sollte Sprint-Planning dauern?

Der Scrum Guide sieht für einen einmonatigen Sprint maximal 8 Stunden vor, proportional skaliert für kürzere Sprints. Für einen Zwei-Wochen-Sprint bedeutet das maximal 4 Stunden, obwohl gut vorbereitete Teams routinemäßig in 2 Stunden oder weniger fertig sind. Wenn Sprint-Planning konsequent zu lang läuft, ist die Ursache fast immer ein unzureichend verfeinerter Backlog oder ein Sprint-Ziel, auf das sich das Team nicht vor Meeting-Beginn geeinigt hat.

Was ist die Definition of Ready?

Die Definition of Ready (DoR) ist eine team-definierte Checkliste, die ein Product Backlog Item erfüllen muss, bevor es für Sprint-Planning geeignet ist. Häufige DoR-Kriterien umfassen schriftliche Akzeptanzkriterien, eine Story-Point-Schätzung, identifizierte Abhängigkeiten und einen Scope, der klein genug ist, um in einen einzelnen Sprint zu passen. Die DoR ist kein Scrum-Guide-Konzept, sondern eine weit verbreitete Praxis, die verhindert, dass Teams Stories einbeziehen, die nicht wirklich bereit sind. Teams vereinbaren ihre DoR in einer Retrospektive und aktualisieren sie mit zunehmendem Lernen.

Wer nimmt an Sprint-Planning teil?

Die erforderlichen Teilnehmer sind Product Owner, Scrum Master und das vollständige Entwicklungsteam. Der Product Owner präsentiert und priorisiert Backlog-Einheiten; das Entwicklungsteam stellt Fragen, schätzt und wählt Einheiten aus; der Scrum Master moderiert und beseitigt Processproblem. Manager, Stakeholder und Kunden nehmen nicht teil. Ihre Anforderungen werden durch die Product Backlog Items repräsentiert, die der Product Owner zum Meeting mitbringt.

Was ist der Unterschied zwischen Sprint-Planning und Backlog-Verfeinerung?

Backlog-Verfeinerung (manchmal auch Backlog-Grooming genannt) ist eine fortlaufende Aktivität, bei der Product Owner und Team Backlog-Einheiten überprüfen, schätzen und klären, bevor sie für Sprint-Planning benötigt werden. Sprint-Planning ist das formale, zeitlich begrenzte Meeting, das jeden Sprint eröffnet. Verfeinerung als Vorbereitung betrachten und Sprint-Planning als Entscheidungsmeeting. Teams, die Verfeinerung überspringen, erledigen im Sprint-Planning-Meeting beide Jobs gleichzeitig, weshalb diese Sitzungen lang laufen und unsichere Verpflichtungen produzieren.

Was passiert, wenn das Team sich nicht genug Arbeit verpflichten kann?

Wenn die Kapazität des Teams ungewöhnlich niedrig ist (Urlaub, Krankheit, konkurrierende Prioritäten), sollte Sprint-Planning das ehrlich widerspiegeln. Weniger Einheiten auswählen, ein kleineres Sprint-Ziel setzen und den reduzierten Scope den Stakeholdern kommunizieren, bevor der Sprint beginnt. Einen Niedrig-Kapazitäts-Sprint nicht mit ambitionierten Zielen oder Einheiten füllen, die das Team nicht fertigstellen kann. Ein kleinerer verbindlicher Scope, der geliefert wird, übertrifft einen ambitionierten Scope, der teilweise geliefert wird und Stakeholder im Unklaren lässt, was tatsächlich fertig ist.

---

Effektives Sprint-Planning dreht sich nicht darum, so viel Arbeit wie möglich in zwei Wochen zu packen. Es geht darum, die richtige Arbeit auszuwählen, sich auf deren Relevanz zu einigen und das gemeinsame Vertrauen aufzubauen, dass das Team liefern kann, was es versprochen hat. Wenn Sprint-Planning gut funktioniert, läuft der Sprint fast von selbst, und genau so sollte es sich anfühlen.