Sprint-Planung: 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 Klarheit 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 das 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

These two ceremonies are often confused. Backlog refinement happens before sprint planning — the team reviews, estimates, and clarifies upcoming items so they are ready to pull into a sprint. Sprint planning is when the team commits to a specific set of items for the upcoming sprint. Refinement prepares the ingredients; planning cooks the meal.

Warum Sprint Planning wichtig ist

Das Auslassen oder überhastete Durchführen des Sprint Planning ist eine der häufigsten Ursachen für das Scheitern von Sprints. Ohne eine gut geführte Planungssitzung summieren sich während des Sprints mehrere Probleme:

Kein gemeinsames Ziel. Einzelne Teammitglieder arbeiten auf Basis unterschiedlicher Annahmen darüber, was am wichtigsten ist.
Kapazität nicht berücksichtigt. Teams übernehmen sich und liefern nicht, 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 “fertig” für jeden etwas anderes.

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

Drei Voraussetzungen für das Sprint Planning

Backlog

Capacity

Goal

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

Input 1: A Refined Product Backlog

Backlog items should be estimated, have clear acceptance criteria, and be ordered by priority. If items arrive at planning unestimated or unclear, the session becomes a discovery meeting. Complete at least one refinement session in the week before sprint planning.

Input 2: Team Capacity

Before the session, calculate available capacity for the sprint — accounting for working days, planned time off, holidays, and non-sprint commitments like on-call rotations. Capacity is typically expressed in story points or hours. The sprint backlog should not exceed available capacity.

Input 3: Last Sprint's Velocity

Velocity — the story points or tasks completed in recent sprints — gives a realistic baseline for how much the team can commit to. Teams that plan based on ideal capacity rather than actual velocity consistently over-commit.

Die zweigeteilte Struktur des Sprint Planning

Der Scrum Guide definiert das Sprint Planning als einen Prozess mit zwei Teilen, die jeweils eine unterschiedliche 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 einzelne, 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.

Schritt-für-Schritt-Anleitung für das Sprint Planning

Sprint Planning Steps

Review refined backlog items

Confirm team capacity

Select items for sprint backlog

Before the Meeting

Ensure backlog items are refined, estimated, and have clear acceptance criteria. Calculate team capacity and review the previous sprint's velocity. The Product Owner should prepare a draft sprint goal — the team will refine it together.

Step 1: Open the Session (5-10 minutes)

Review the sprint goal — a one-sentence statement of the sprint's primary objective. A good sprint goal is outcome-oriented, not output-oriented. "Complete six user stories" is an output goal. "Enable users to complete checkout without creating an account" is an outcome goal.

Step 2: Select Sprint Backlog Items (30-60 minutes)

Work through backlog items in priority order. For each: the Product Owner explains acceptance criteria, the team discusses complexity and dependencies, and the team decides whether to include it. Stop when capacity is exhausted — do not add items hoping the team will "find a way."

Step 3: Break Items into Tasks (20-40 minutes)

For each selected item, identify the specific tasks required. Tasks should be small enough to complete in one to two days — this ensures blockers surface during daily standups rather than the last day of the sprint. If a task requires a missing skill set, identify the dependency now.

Step 4: Finalize and Commit (5-10 minutes)

Confirm the sprint goal with the full team. Ensure everyone understands what is in the sprint backlog and why. Assign ownership of the first tasks so the sprint has clear momentum from day one.

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-90 Minuten, wenn das Backlog gut vorbereitet ist.

Recommended Time Box by Sprint Length

Sprint Length	Maximum Planning Duration
1 week	2 hours
2 weeks	4 hours
3 weeks	6 hours
4 weeks	8 hours

Wenn Ihre Sitzungen regelmäßig den Zeitrahmen überschreiten, ist die Ursache fast immer ein unzureichendes Backlog Refinement – nicht das Planungsmeeting selbst.

Häufige Fehler beim Sprint Planning

Mistakes That Derail Sprint Planning

No sprint goal — without a unifying goal, there is no framework for reprioritization when surprises hit
Over-committing to heroics — a sprint plan that requires overtime is simply a wrong plan
Including items that are not ready — unestimated items without acceptance criteria cannot be planned accurately
Assigning all tasks at planning — over-assignment prevents the team from self-organizing around blockers
Not reviewing the previous sprint — unfinished items must be explicitly re-estimated, not auto-carried over

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ät mit Velocity-Charts, Sprint-Backlog-Ansichten und Burndown-Charts.

Linear ist eine schnellere, sauberere Alternative zu Jira, beliebt bei Produkt-Engineering-Teams, 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 Prototypenphasen 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 verwenden, 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 ist die häufigste Sprint-Länge und funktioniert für die meisten Teams gut. Einwöchige Sprints funktionieren für Teams, die schnelle Feedbackzyklen benötigen und gut verfeinerte Backlogs haben. Vermeiden Sie Sprints, die länger als vier Wochen dauern – die Feedbackschleife wird zu langsam, um 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 Bugs oder ungeplanter Arbeit während eines Sprints um?

Die meisten Teams reservieren 10-20 % der Sprint-Kapazität als Puffer für Bugs 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 Zweier-Team 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: 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. Die Teams, die sich darüber ärgern, sind meist diejenigen, die es falsch machen – mit unvorbereiteten Backlogs, ohne Sprint-Ziel und mit zwei Stunden improvisierter Schätzung.

Richtig durchgeführt, dauert das Sprint Planning sechzig bis neunzig Minuten, hinterlässt das Team mit klaren 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