Sprint Planning: So führen Sie 2026 eine effektive Sitzung durch

Sprint Planning ist die Zeremonie, die Teams, die beständig Ergebnisse liefern, von Teams unterscheidet, die sich ständig im Chaos verlieren. Wenn sie gut durchgeführt wird, schafft sie eine Abstimmung darüber, welche Arbeit im nächsten Sprint erledigt wird, wie sie erledigt wird und wer dafür verantwortlich ist.

Wenn sie schlecht durchgeführt wird, ist es ein zweistündiges Meeting, nach dem alle verwirrt darüber sind, was eigentlich vereinbart wurde.

Was ist Sprint Planning?

Sprint Planning ist ein zeitlich begrenztes Meeting in Scrum, in dem das Team definiert, was es im kommenden Sprint liefern wird und wie es dies erreichen will. Ein Sprint ist ein Entwicklungszyklus mit fester Dauer, typischerweise ein bis vier Wochen, und Sprint Planning ist das erste Ereignis in diesem Zyklus.

Das Ergebnis des Sprint Planning ist das Sprint Backlog: eine Menge von Elementen aus dem Product Backlog, die vom Team verfeinert wurden und zu denen es sich verpflichtet hat, mit genügend Details, um sofort mit der Arbeit beginnen zu können.

Sprint Planning vs. Backlog Refinement

Diese beiden Zeremonien werden oft verwechselt. Backlog Refinement findet vor dem Sprint Planning statt. Das Team überprüft, schätzt und klärt anstehende Elemente, damit sie bereit sind, in einen Sprint gezogen zu werden. Sprint Planning ist der Zeitpunkt, an dem sich das Team auf eine bestimmte Menge von Elementen für den kommenden Sprint festlegt. Refinement bereitet die Zutaten vor, Planning kocht das Gericht.

Warum Sprint Planning wichtig ist

Das Auslassen oder Überstürzen des Sprint Planning ist eine der häufigsten Ursachen für das Scheitern von Sprints. Ohne eine gut geführte Planungsrunde summieren sich während des Sprints mehrere Probleme.

Kein gemeinsames Ziel. Einzelne Mitwirkende arbeiten auf Basis unterschiedlicher Annahmen darüber, was am wichtigsten ist.
Kapazität nicht berücksichtigt. Teams übernehmen sich und liefern nicht ab, oder sie planen zu vorsichtig und lassen Wertpotenzial ungenutzt.
Arbeit nicht heruntergebrochen. Große, vage Aufgaben geraten ins Stocken, wenn das Team mitten im Sprint auf versteckte Komplexität stößt.
Keine Definition of Done. Ohne gemeinsame Akzeptanzkriterien bedeutet “erledigt” für verschiedene Leute unterschiedliche Dinge.

Eine gut geführte Sprint-Planning-Sitzung löst all diese Probleme, bevor der Sprint beginnt.

Drei Voraussetzungen für das Sprint Planning

Backlog

Kapazität

Ziel

Effektives Sprint Planning erfordert, dass drei Dinge in gutem Zustand sind, bevor das Meeting beginnt. Ohne diese Vorbereitung wird das Planning zu einem Discovery-Meeting, was das falsche Meeting für diesen Zweck ist.

Input 1: Ein verfeinertes Product Backlog

Backlog-Elemente sollten geschätzt sein, klare Akzeptanzkriterien haben und nach Priorität geordnet sein. Wenn Elemente ungeschätzt oder unklar im Planning ankommen, wird die Sitzung zu einem Discovery-Meeting. Führen Sie in der Woche vor dem Sprint Planning mindestens eine Refinement-Sitzung durch.

Input 2: Teamkapazität

Berechnen Sie vor der Sitzung die verfügbare Kapazität für den Sprint. Berücksichtigen Sie dabei Arbeitstage, geplante Abwesenheiten, Feiertage und Verpflichtungen außerhalb des Sprints, wie etwa On-Call-Dienste. Die Kapazität wird typischerweise in Story Points oder Stunden ausgedrückt. Das Sprint Backlog sollte die verfügbare Kapazität nicht überschreiten.

Input 3: Velocity des letzten Sprints

Die Velocity, also die in den letzten Sprints abgeschlossenen Story Points oder Aufgaben, bietet eine realistische Basis dafür, wie viel das Team zusagen kann. Teams, die auf Basis idealer Kapazität statt tatsächlicher Velocity planen, übernehmen sich regelmäßig.

Die zweiteilige Struktur des Sprint Planning

Der Scrum Guide definiert das Sprint Planning als einen Prozess mit zwei Teilen, die jeweils eine eigene Frage adressieren. Beide Teile müssen abgeschlossen sein, bevor der Sprint beginnt.

Teil 1: Was kann in diesem Sprint erledigt werden? Der Product Owner präsentiert die Backlog-Elemente mit der höchsten Priorität. Das Team diskutiert jedes Element, stellt klärende Fragen und bestimmt, welche Elemente in die verfügbare Kapazität passen. Das Ergebnis ist das Sprint Backlog.

Teil 2: Wie wird die Arbeit erledigt? Für jedes ausgewählte Element diskutiert das Team den technischen Ansatz und unterteilt ihn in Aufgaben. Diese Zerlegung deckt versteckte Komplexität auf, bevor die Arbeit beginnt, und erstellt die tägliche Aufgabenliste, die die Ausführung leitet.

So führen Sie das Sprint Planning Schritt für Schritt durch

Sprint Planning Schritte

Verfeinerte Backlog-Elemente überprüfen

Teamkapazität bestätigen

Elemente für das Sprint Backlog auswählen

Vor dem Meeting

Stellen Sie sicher, dass Backlog-Elemente verfeinert und geschätzt sind und klare Akzeptanzkriterien haben. Berechnen Sie die Teamkapazität und überprüfen Sie die Velocity des vorherigen Sprints. Der Product Owner sollte einen Entwurf für das Sprint-Ziel vorbereiten, den das Team gemeinsam verfeinern wird.

Schritt 1: Eröffnung der Sitzung (5-10 Minuten)

Überprüfen Sie das Sprint-Ziel, eine Ein-Satz-Aussage über das Hauptziel des Sprints. Ein gutes Sprint-Ziel ist ergebnisorientiert, nicht output-orientiert. "Sechs User Stories abschließen" ist ein Output-Ziel. "Benutzern ermöglichen, den Checkout ohne Kontoerstellung abzuschließen" ist ein Ergebnis-Ziel.

Schritt 2: Auswahl der Sprint-Backlog-Elemente (30-60 Minuten)

Arbeiten Sie die Backlog-Elemente in der Prioritätsreihenfolge ab. Für jedes Element: Der Product Owner erklärt die Akzeptanzkriterien, das Team diskutiert Komplexität und Abhängigkeiten, und das Team entscheidet, ob es aufgenommen wird. Stoppen Sie, wenn die Kapazität erschöpft ist. Fügen Sie keine Elemente in der Hoffnung hinzu, dass das Team "einen Weg finden wird".

Schritt 3: Unterteilung der Elemente in Aufgaben (20-40 Minuten)

Identifizieren Sie für jedes ausgewählte Element die spezifisch erforderlichen Aufgaben. Aufgaben sollten klein genug sein, um sie in ein bis zwei Tagen abzuschließen. Dies stellt sicher, dass Blocker während der Daily Standups auftauchen und nicht erst am letzten Tag des Sprints. Wenn eine Aufgabe eine fehlende Fähigkeit erfordert, identifizieren Sie die Abhängigkeit jetzt.

Schritt 4: Finalisierung und Commitment (5-10 Minuten)

Bestätigen Sie das Sprint-Ziel mit dem gesamten Team. Stellen Sie sicher, dass jeder versteht, was im Sprint Backlog enthalten ist und warum. Weisen Sie die Verantwortung für die ersten Aufgaben zu, damit der Sprint vom ersten Tag an eine klare Dynamik hat.

Zeitrahmen für das Sprint Planning

Der Scrum Guide empfiehlt, das Sprint Planning basierend auf der Sprint-Länge zeitlich zu begrenzen. In der Praxis dauern die meisten zweiwöchigen Sitzungen 60 bis 90 Minuten, wenn das Backlog gut vorbereitet ist.

Empfohlener Zeitrahmen nach Sprint-Länge

Sprint-Länge	Maximale Planungsdauer
1 Woche	2 Stunden
2 Wochen	4 Stunden
3 Wochen	6 Stunden
4 Wochen	8 Stunden

Wenn Ihre Sitzungen regelmäßig den Zeitrahmen überschreiten, liegt die Ursache fast immer in einer unzureichenden Backlog-Verfeinerung und nicht am Planungsmeeting selbst.

Häufige Fehler beim Sprint Planning

Fehler, die das Sprint Planning entgleisen lassen

Kein Sprint-Ziel: Ohne ein verbindendes Ziel gibt es keinen Rahmen für eine Neupriorisierung, wenn Überraschungen auftreten.
Übernahme von Heldentaten: Ein Sprint-Plan, der Überstunden erfordert, ist schlichtweg ein falscher Plan.
Einbeziehung von Elementen, die nicht bereit sind: Ungeschätzte Elemente ohne Akzeptanzkriterien können nicht präzise geplant werden.
Zuweisung aller Aufgaben beim Planning: Eine zu starke Zuweisung verhindert, dass sich das Team selbst um Blocker organisiert.
Keine Überprüfung des vorherigen Sprints: Nicht abgeschlossene Elemente müssen explizit neu geschätzt werden, anstatt sie automatisch zu übernehmen.

Tools für das Sprint Planning

Sprint Planning

Sprint Board

Das richtige Tool hängt davon ab, ob Ihr Team am selben Ort arbeitet oder verteilt ist. Für verteiltes Sprint Planning ist ein gemeinsames Board, das jeder gleichzeitig sehen und bearbeiten kann, unerlässlich.

Jira ist der Standard für Softwareentwicklungsteams. Es verfügt über native Sprint-Funktionalitäten mit Velocity-Diagrammen, Sprint-Backlog-Ansichten und Burndown-Charts.

Linear ist eine schnellere, sauberere Alternative zu Jira, die bei Produktentwicklungsteams beliebt ist, denen Jira zu überladen ist.

TasksBoard: Für Teams, die Aufgaben in Google Tasks verwalten, ermöglicht das Kanban-Board von TasksBoard die Bearbeitung durch mehrere Personen in Echtzeit, was es zu einer leichtgewichtigen Option für kleinere Teams macht, die informelle Sprints durchführen. Sehen Sie sich unseren Vergleich von Agile-Tools an, um die richtige Wahl zu treffen.

Für Teams vor Ort oder hybride Teams nutzen viele ein physisches oder digitales Whiteboard für das Sprint Planning und übertragen die zugesagten Elemente anschließend in ihr Aufgabenverwaltungssystem. Kein Tool ersetzt die Qualität Ihrer Backlog-Vorbereitung oder die Klarheit Ihres Sprint-Ziels.

Sprint Planning außerhalb von Softwareteams

Sprint Planning hat seinen Ursprung in der Softwareentwicklung, aber die Struktur lässt sich auf jedes Team anwenden, das iterative Projektarbeit leistet. Marketingteams nutzen Sprints, um Kampagnenzyklen zu planen. Designteams nutzen Sprints, um Forschungs-, Konzept- und Prototyping-Phasen zu strukturieren. Betriebsteams nutzen Sprint-artige Planung, um Prozessverbesserungsprojekte zu bündeln.

Die wichtigste Anpassung für Nicht-Softwareteams ist die Schätzung. Story Points sind für die Unsicherheit in der Softwareentwicklung konzipiert. Marketing- und Betriebsteams finden zeitbasierte Schätzungen oft einfacher.

Für nicht-technische Teams, die Google Workspace nutzen, bietet eine Kombination aus Google Tasks für das Backlog-Management und TasksBoard für das Sprint-Board ein leichtgewichtiges Setup, ohne eine vollständige Projektmanagement-Plattform einführen zu müssen.

Häufig gestellte Fragen

Wie lang sollte ein Sprint sein?

Zwei Wochen sind die häufigste Sprint-Länge und funktionieren für die meisten Teams gut. Einwöchige Sprints funktionieren für Teams, die schnelle Feedback-Zyklen benötigen und gut verfeinerte Backlogs haben. Vermeiden Sie Sprints, die länger als vier Wochen dauern, da die Feedback-Schleife zu langsam wird, um die Agilität aufrechtzuerhalten.

Wer moderiert das Sprint Planning?

Der Scrum Master moderiert das Sprint Planning. In Teams ohne formellen Scrum Master wird die Rolle oft vom Tech Lead oder einem rotierenden Teammitglied ausgefüllt. Der Product Owner beantwortet Fragen zu Backlog-Elementen, kontrolliert aber nicht, wie das Team die Arbeit plant.

Was passiert mit Elementen, die es nicht in den Sprint schaffen?

Elemente, die nicht ausgewählt wurden, verbleiben im Product Backlog. Der Product Owner priorisiert das Backlog nach dem Sprint Planning neu und bereitet die obersten Elemente für den folgenden Sprint durch Backlog Refinement vor.

Wie geht man mit Fehlern oder ungeplanter Arbeit während eines Sprints um?

Die meisten Teams reservieren 10-20% der Sprint-Kapazität als Puffer für Fehler und dringende Anfragen. Wenn ungeplante Arbeit den Puffer überschreitet, diskutieren das Team und der Product Owner, welche geplanten Elemente verschoben werden können.

Was ist ein Sprint-Ziel und warum ist es wichtig?

Ein Sprint-Ziel ist eine Ein-Satz-Aussage darüber, was das Team erreichen will. Es ist wichtig, weil es einen Entscheidungsrahmen bietet, wenn das Team vor Kompromissen steht. Wenn ein Blocker eine Neupriorisierung erzwingt, verdeutlicht das Sprint-Ziel, welche Elemente wesentlich sind und welche verschoben werden können.

Kann man Sprint Planning mit einem kleinen Team machen?

Ja. Ein Zweierteam kann eine sinnvolle Sprint-Planning-Sitzung in zwanzig Minuten mit einem verfeinerten Backlog und einem klaren Ziel durchführen. Die Struktur der Zeremonie ist weniger wichtig als die Ergebnisse: ein gemeinsames Verständnis darüber, was getan wird, wie und von wem.

Fazit

Sprint Planning ist kein bürokratischer Overhead. Es ist die Investition, die den Rest des Sprints reibungslos laufen lässt. Teams, die sich darüber ärgern, machen es meist falsch, mit unvorbereiteten Backlogs, ohne Sprint-Ziel und mit zwei Stunden spontaner Schätzung.

Richtig durchgeführt, dauert das Sprint Planning sechzig bis neunzig Minuten, hinterlässt dem Team klare Zusagen und eliminiert die häufigsten Ursachen für Verwirrung während des Sprints. Beginnen Sie mit einem klaren Sprint-Ziel, einem verfeinerten Backlog und einer ehrlichen Kapazitätsplanung.

Entdecken Sie das Kanban-Board von TasksBoard für Google Tasks