Sprint Planning: Ablauf, Agenda, Timebox und Vorlagen (2026)

Das Sprint Planning ist das Meeting, das darüber entscheidet, wie die nächsten zwei Wochen Arbeit eines ganzen Teams eingesetzt werden. Kein anderes Meeting im agilen Kalender hat so viel Hebelwirkung pro Stunde: Ein unscharfes Sprint-Ziel kostet hier zehn Tage verstreuter Arbeit, ein unvorbereitetes Backlog kostet zwei Stunden lautes Ticket-Vorlesen vor versammelter Mannschaft.

Trotzdem verkommen viele Sprint Plannings zum Verteilen von Aufgaben aus einer Liste. Das Team verlässt den Raum mit einem randvollen Sprint, ohne ein Ziel, das in einen Satz passt, und mit dem Gefühl, einer Ticket-Versteigerung beigewohnt zu haben. Zwei Wochen später bestätigt das Sprint Review das Unvermeidliche, und die Retrospektive notiert zum wiederholten Mal „besser planen".

Dieser Leitfaden erklärt, was Sprint Planning wirklich ist und wie man eines leitet, das einen echten Plan hervorbringt: die 3 Fragen, die es strukturieren, die richtige Dauer je Sprint-Länge, eine praxiserprobte Agenda für 2-Wochen-Sprints, die häufigsten Fehler, Vorlagen zum Kopieren und ein Weg, Entscheidungen und Akzeptanzkriterien festzuhalten, ohne einen Protokollführer zu benennen.

⚠️ Dieser Artikel wurde auf Grundlage öffentlich zugänglicher Informationen und Nutzerfeedbacks mit Stand August 2026 unabhängig zusammengestellt.

Inhaltsverzeichnis

1. Was ist Sprint Planning?
2. Planning, Review, Retro, Refinement: die Scrum-Events im Überblick
3. Die 3 Fragen, die das Sprint Planning strukturieren
4. Wie lange sollte ein Sprint Planning dauern?
5. Eine Agenda für den 2-Wochen-Sprint
6. Typische Fehler im Sprint Planning
7. Sprint-Planning-Vorlagen zum Kopieren
8. Vom Planning zum Protokoll, ohne Protokollführer
9. Häufige Fragen
10. Fazit

Was ist Sprint Planning?

Das Sprint Planning ist das Meeting, mit dem jeder Sprint beginnt: Das gesamte Scrum-Team legt fest, welchen Wert es in den kommenden Wochen liefern will, wählt die Backlog-Einträge aus, die das möglich machen, und skizziert einen Plan dorthin. Das Ergebnis hat einen eigenen Namen: das Sprint Backlog, bestehend aus Sprint-Ziel, ausgewählten Einträgen und Lieferplan.

Im Deutschen kursieren mehrere Bezeichnungen nebeneinander: „Sprint Planning", „Sprint-Planung" oder im Alltag schlicht „das Planning". Gemeint ist immer dasselbe offizielle Scrum-Event aus dem Scrum Guide.

Zwei Abgrenzungen schärfen die Definition. Erstens: Das Sprint Planning ist nicht der Ort, um das Backlog zu entdecken. Kandidaten sollten bereits verfeinert ankommen: verstanden, geschätzt und mit Akzeptanzkriterien versehen. Liest das Team Tickets zum ersten Mal im Planning, wird das Meeting zu einer teuren Refinement-Runde mit voller Besetzung. Zweitens: Das Ergebnis ist keine Aufgabenliste, sondern ein Commitment auf ein Ziel. Der Unterschied zeigt sich, wenn mitten im Sprint etwas schiefgeht: Ein Team mit Ziel verhandelt den Umfang neu; ein Team mit Aufgabenliste ist einfach nur zu spät.

Es nimmt das komplette Scrum-Team teil: die Entwickler, die entscheiden, wie viel Arbeit hineinpasst und wie sie erledigt wird; der Product Owner, der Zweck und Prioritäten mitbringt; und der Scrum Master, der darauf achtet, dass das Meeting liefert, was es soll. Weitere Personen können zur Beratung eingeladen werden, aber die Entscheidung, wie viel in den Sprint passt, gehört denen, die die Arbeit machen.

Planning, Review, Retro, Refinement: die Scrum-Events im Überblick

Das Sprint Planning wird regelmäßig mit den anderen Meetings des Zyklus verwechselt. Die Tabelle sortiert die Rollen:

Die wichtigste Beziehung ist die zwischen Refinement und Planning: Refinement ist die Vorbereitung, Planning die Entscheidung. Teams, die unter endlosen Plannings leiden, haben fast immer ein Refinement-Problem, kein Planungsproblem. Eine verbreitete Faustregel: Zu Beginn des Plannings sollten die nächsten zwei Sprints an Backlog im Zustand „bereit zur Auswahl" sein.

Die 3 Fragen, die das Sprint Planning strukturieren

Der Scrum Guide gliedert das Sprint Planning in drei Themen, die als natürliches Drehbuch des Meetings funktionieren:

1. Warum ist dieser Sprint wertvoll?

Der Product Owner schlägt vor, wo der Sprint den größten Wert stiften kann: Was braucht das Produkt jetzt, was erwarten die Stakeholder, welches Wissen fehlt noch. Auf dieser Grundlage formuliert das gesamte Team das Sprint-Ziel: ein Satz, der den Zweck erklärt, keine Summe von Tickets. „Ein neuer Nutzer schließt die Registrierung ohne Hilfe ab" ist ein Ziel; „die 12 Tickets des Sprints abarbeiten" ist keines.

Das Ziel muss stehen, bevor das Planning endet. Es ist der Kompass für den Rest des Sprints: Wenn Überraschungen kommen, schützt das Team das Ziel und verhandelt alles andere neu.

2. Was kann in diesem Sprint erledigt werden?

Die Entwickler wählen Einträge aus dem Product Backlog und klären offene Fragen im Gespräch mit dem Product Owner. Hier kommen die nüchternen Zahlen ins Spiel: die reale Kapazität des Teams (Urlaub, Feiertage, Support-Dienst, Meetings) und die Erfahrungswerte vergangener Sprints. Wie viel hineinpasst, ist eine schwierige Vorhersage, und genau deshalb treffen sie diejenigen, die die Arbeit ausführen, nicht diejenigen, die sie anfordern.

Die klassische Falle: für das ideale Team in einem störungsfreien Sprint zu planen. Erfahrene Teams reservieren einen expliziten Puffer, oft 15 bis 20 Prozent, für das Unplanbare, und das kommt sie günstiger, als so zu tun, als gäbe es das nicht.

3. Wie wird die Arbeit erledigt?

Für die ersten Einträge zerlegen die Entwickler die Arbeit in kleine Pakete, idealerweise von einem Tag oder weniger. Es muss nicht der ganze Sprint im Meeting zerlegt werden: Genug, um sicher zu starten, genügt. Dieser Plan gehört allein den Entwicklern; niemand sonst bestimmt, wie sie Backlog in ein Increment verwandeln.

Wie lange sollte ein Sprint Planning dauern?

Der Scrum Guide setzt die Obergrenze: maximal 8 Stunden für einen Ein-Monats-Sprint, proportional weniger für kürzere Sprints. In der Praxis arbeiten die meisten Teams mit 2-Wochen-Sprints und sind deutlich unter dem theoretischen Maximum fertig:

Zwei nützliche Lesarten der Tabelle: Wenn euer Planning regelmäßig nach 20 Minuten vorbei ist, wird vermutlich nichts geplant, sondern eine Liste abgenickt. Wenn es die Timebox jedes Mal ausreizt, kommt das Backlog unverfeinert an oder das Team betreibt das komplette technische Design im Meeting. Beide Extreme sind Symptome, keine Stilfragen.

Eine Agenda für den 2-Wochen-Sprint

Eine praxiserprobte 2-Stunden-Struktur, die die drei Themen des Guides in Blöcke mit Uhr übersetzt:

1. Kontext und Kapazität (10 Min.). Das Ergebnis des letzten Sprints in zwei Sätzen, Neuigkeiten mit Einfluss auf den Plan und die reale Kapazität: Wer fehlt, welche Feiertage liegen im Sprint, wie viel Support-Arbeit ist zu erwarten.
2. Wertvorschlag und Sprint-Ziel (25 Min.). Der Product Owner erklärt das Warum. Das Team diskutiert und formuliert das Ziel in einem Satz, sichtbar für alle. Weiter geht es erst, wenn der Satz steht.
3. Auswahl der Einträge (40 Min.). Die verfeinerten Kandidaten werden durchgegangen, Umfangsfragen und Akzeptanzkriterien geklärt und der Sprint auf Kapazität zugeschnitten. Jeder Eintrag kommt mit Begründung hinein: Er zahlt auf das Ziel ein oder ist eine unvermeidbare Verpflichtung.
4. Umsetzungsplan (30 Min.). Die ersten Einträge werden in Tagespakete zerlegt. Abhängigkeiten zwischen Personen und zu anderen Teams werden benannt, ebenso bekannte Risiken.
5. Bestätigung und Abschluss (15 Min.). Das Ziel wird noch einmal vorgelesen, der finale Zuschnitt geprüft, und jede offene Frage verlässt den Raum mit einem Verantwortlichen. Das Sprint Backlog wird dort veröffentlicht, wo das ganze Team es täglich sieht.

Die Agenda skaliert nach unten für Ein-Wochen-Sprints (jeden Block halbieren) und nach oben für Monats-Sprints. Was sich nie ändert, ist die Reihenfolge: erst das Warum, dann das Was, zuletzt das Wie. Wer die Reihenfolge umkehrt, produziert Sprints, die technisch stimmig und strategisch leer sind.

Typische Fehler im Sprint Planning

• Planen ohne Sprint-Ziel. Der teuerste Fehler. Ohne einen Satz, der den Zweck erklärt, ist der Sprint ein Sack voller Tickets, und jede Überraschung wird mit Panik statt mit Priorität behandelt. Untrügliches Zeichen: Am zweiten Mittwoch kann niemand im Team das Ziel aufsagen.
• Refinement im Planning nachholen. Tickets zum ersten Mal lesen, schätzen und Design diskutieren, während das ganze Team zusieht, macht aus einem 2-Stunden-Meeting ein 4-Stunden-Meeting. Refinement ist eine laufende Aktivität im Sprint, kein Block im Planning.
• Mit 100 Prozent Kapazität planen. Ein randvoller Sprint hat keinen Platz für den dringenden Bug oder die Frage, die größer wird. Der explizite Puffer ist kein Pessimismus, sondern der Unterschied zwischen Neuverhandeln und Scheitern.
• Der Product Owner entscheidet, wie viel passt. Der Druck von „das muss aber rein" vertauscht die Rollen. Der Product Owner ordnet nach Wert; wie viel passt, entscheiden die, die die Arbeit machen. Bricht diese Grenze, werden aus Schätzungen Verhandlungen.
• Commitment mit Garantie verwechseln. Das Sprint Backlog ist eine ehrliche Prognose, kein Vertrag. Teams, die für „verfehlte Sprints" bestraft werden, lernen schnell, Schätzungen zu polstern, und die gesamte Planung verliert ihren Informationswert.
• Entscheidungen, die sich verflüchtigen. „Was hatten wir noch mal zur Migration entschieden?", gefragt am Donnerstag der ersten Woche, ist das klassische Symptom. Die Feinheiten des Zuschnitts, mündlich geklärte Akzeptanzkriterien und entdeckte Abhängigkeiten werden einmal ausgesprochen und nirgends notiert.
• Das Planning ausfallen lassen, „weil eh klar ist, was ansteht". Ein Sprint, der ohne Auftakt-Meeting beginnt, erbt den impliziten Plan von irgendwem. Das funktioniert, bis es nicht mehr funktioniert, und dann erinnert sich niemand, je etwas vereinbart zu haben.

Sprint-Planning-Vorlagen zum Kopieren

1. Agenda mit Uhrzeiten (für die Einladung)

# Sprint Planning [Team] - Sprint [Nr.] - [Datum] (2 h)
Voraussetzung: Kandidaten im Backlog verfeinert und geschätzt

10 Min. - Kontext und Kapazität (Abwesenheiten, Feiertage, Support)
25 Min. - Sprint-Ziel (gemeinsam formuliert, 1 Satz)
40 Min. - Auswahl der Einträge und Zuschnitt auf Kapazität
30 Min. - Zerlegung der ersten Einträge und Abhängigkeiten
15 Min. - Bestätigung: Ziel + Zuschnitt + offene Fragen mit Verantwortlichen

2. Minimales Sprint Backlog (das Ergebnisdokument)

# Sprint [Nr.] - [Zeitraum]
## Sprint-Ziel
[1 Satz, der den Zweck erklärt]

## Kapazität
Verfügbare Personentage: [n] | Puffer für Ungeplantes: [%]

## Ausgewählte Einträge
- [Eintrag] - [erste Verantwortung] - Akzeptanzkriterien: [Link oder Kurzfassung]
- ...

## Entscheidungen und Vereinbarungen aus dem Planning
- [Entscheidung] - [Kontext in 1 Zeile]

## Abhängigkeiten und Risiken
- [Abhängigkeit] - abhängig von: [Person/Team] - benötigt bis: [Tag]

## Nicht in diesem Sprint (angefragt, aber gestrichen)
- [Eintrag] - Grund für den Schnitt

3. Checkliste für den Product Owner (am Vortag)

[ ] Kandidaten für die nächsten 2 Sprints sind verfeinert und geschätzt
[ ] Jeder Kandidat hat schriftliche Akzeptanzkriterien
[ ] Der Vorschlag für das Sprint-Ziel passt in einen Satz
[ ] Das Ergebnis des letzten Sprints ist in 2 Sätzen zusammengefasst
[ ] Stakeholder mit Last-Minute-Wünschen wurden gehört (oder zum Review eingeladen)

Vom Planning zum Protokoll, ohne Protokollführer

Das Sprint Planning produziert mehr Entscheidungen pro Stunde als fast jedes andere Meeting: das Ziel, den exakten Zuschnitt, mündlich geklärte Akzeptanzkriterien, Abhängigkeiten, Risiken, was draußen blieb und warum. Und fast alles davon wird ausgesprochen, während alle auf das Board schauen, nicht auf das Protokoll. Einen Protokollführer zu benennen löst das Problem auch nicht: Wer mitschreibt, hört auf zu schätzen und zu diskutieren, ausgerechnet in dem Meeting, in dem sein Urteil am meisten zählt.

Hier passt ein KI-Meeting-Assistent in Echtzeit. SuperIntern ist eine botlose Desktop-App (Mac und Windows), die das Meeting direkt vom Geräte-Audio aufnimmt: Kein Geister-Teilnehmer betritt den Call, und es funktioniert gleichermaßen in Zoom, Google Meet, Microsoft Teams, Webex oder im Raum am physischen Board.

Im Planning ergibt das einen konkreten Ablauf:

• Gebt AI Canvas die Struktur eures Sprint Backlogs. Einmal in normaler Sprache beschreiben: „Erfasse das Sprint-Ziel als wörtliches Zitat, die ausgewählten Einträge als Tabelle mit Verantwortlichen und Kriterien, Entscheidungen als Liste und Gestrichenes mit Begründung." Über die 2 Stunden füllt sich die Live-Notiz von selbst in genau dieser Form.

• Fragt den KI-Chat, ohne das Meeting anzuhalten. „Was haben wir dafür im Refinement am Dienstag geschätzt?" oder „was wurde im letzten Planning zur Migration entschieden?": Der Chat durchsucht auch vergangene Meetings, die Antwort kommt also, ohne in alten Protokollen zu graben oder die Diskussion zu unterbrechen.

• Mündlich genannte Akzeptanzkriterien stehen schwarz auf weiß. Die verbale Klarstellung des Product Owners, was „fertig" bei einem konkreten Eintrag bedeutet, ist genau das, worüber im Review gestritten wird. Mit Transkript lässt sich der exakte Satz suchen; ohne wird er aus dem Gedächtnis rekonstruiert.
• Wer gefehlt hat, holt ohne Zeremonie auf. Die Zusammenfassung steht, wenn das Meeting endet: Wer im Urlaub war oder als Stakeholder neugierig ist, liest Ziel und Zuschnitt in zwei Minuten.
• Mehrsprachige Teams planen in ihrer Sprache. SuperIntern übersetzt in Echtzeit in über 50 Sprachen, und jede Person kann die Zusammenfassung in ihrer eigenen erhalten, hilfreich, wenn das Planning zwischen München, Mexiko-Stadt und Austin stattfindet.

Eine ehrliche Anmerkung: SuperIntern ist eine Desktop-App für Live-Meetings. Sie verwaltet nicht euer Backlog und ersetzt weder Jira noch Linear; ihr Terrain ist das Planungsgespräch selbst, jenes, in dem Entscheidungen heute verdunsten. Es gibt einen kostenlosen Plan, das nächste Planning damit auszuprobieren kostet also nichts.

Häufige Fragen

Was ist Sprint Planning, kurz gesagt?

Das Meeting, mit dem jeder Sprint beginnt: Das Team definiert ein Ziel, wählt die lieferbaren Backlog-Einträge aus und skizziert den Plan dorthin. Das Ergebnis ist das Sprint Backlog: Ziel, ausgewählte Einträge und Plan.

Wie lange dauert ein Sprint Planning?

Maximal 8 Stunden für einen Ein-Monats-Sprint, proportional weniger für kürzere Sprints. Beim 2-Wochen-Sprint, dem häufigsten Format, sind die meisten Teams in 1,5 bis 2 Stunden fertig, sofern das Backlog verfeinert ankommt.

Wer nimmt am Sprint Planning teil?

Das komplette Scrum-Team: Entwickler, Product Owner und Scrum Master. Fachleute können zur Beratung eingeladen werden. Die Entscheidung, wie viel Arbeit hineinpasst, liegt ausschließlich bei den Entwicklern.

Was ist der Unterschied zwischen Sprint Planning und Backlog Refinement?

Refinement bereitet vor: Es klärt, teilt und schätzt Backlog-Einträge laufend während des Sprints. Planning entscheidet: Es wählt unter vorbereiteten Einträgen aus und baut den Plan. Wird im Planning verfeinert, bezahlt man Vorbereitung zum Preis eines Meetings mit voller Besetzung.

Was ist das Sprint-Ziel und warum ist es so wichtig?

Ein Satz, der den Zweck des Sprints erklärt, formuliert vom ganzen Team während des Plannings. Es zählt, weil es das Kriterium für Neuverhandlungen ist: Wenn eine Überraschung eintrifft, schützt das Team das Ziel und passt den Rest an, statt blind eine Ticketliste zu verteidigen.

Geht Sprint Planning auch ohne Story Points?

Ja. Punkte sind ein Prognosewerkzeug, keine Scrum-Vorschrift. Teams schätzen in T-Shirt-Größen, Idealtagen oder zählen ähnlich große Einträge. Unverzichtbar ist nur, dass die Vorhersage von denen kommt, die die Arbeit machen, gestützt auf vergangene Sprints.

Wie läuft Sprint Planning mit einem Remote-Team ab?

Wie in Präsenz, mit drei Anpassungen: Das geteilte Board am Bildschirm ersetzt die Wand, das Sprint-Ziel steht ab Minute eins in einem sichtbaren Dokument, und das Festhalten der Entscheidungen wird automatisiert, denn Remote-Teams haben keinen Flur, auf dem sich rekonstruieren ließe, was niemand aufgeschrieben hat.

Fazit

Ein Sprint Planning bemisst sich nicht daran, mit vollem Kalender hinauszugehen, sondern an drei Ergebnissen: einem Ziel, das in einen Satz passt, einem Backlog-Zuschnitt, den die Ausführenden gewählt haben, und einem Plan, der reicht, um morgen sicher zu starten. Die 3 Fragen des Guides (Warum, Was, Wie) sind das Drehbuch; Timebox und Kapazitätspuffer die Leitplanken.

Und wie in jedem Meeting, in dem viel in kurzer Zeit entschieden wird, ist das Gedächtnis das schwächste Glied: An das Ziel erinnert man sich, aber mündlich geklärte Kriterien und die Gründe hinter dem Zuschnitt verflüchtigen sich vor dem ersten Daily. Dieses Protokoll braucht keinen Protokollführer mehr: Ein botloser KI-Assistent schreibt die Live-Notiz in der Struktur, die das Team vorgibt, während das Team das Einzige tut, was nur das Team tun kann: den Sprint gut entscheiden.

SuperIntern kostenlos testen : keine Bots im Planning, Ziel und Vereinbarungen festgehalten in dem Moment, in dem sie ausgesprochen werden, und eine teilbare Zusammenfassung zum Schluss.