Sprint-Planning-Agenda-Vorlage für Engineering-Teams

Warum Sprints überlastet werden

Sprint-Planning hat einen strukturellen Fehler, den Vorlagen nicht verhindern: Teams wählen das Sprint-Backlog aus, bevor jemand die Kapazität prüft. Das Ergebnis ist ein Sprint, der auf dem Whiteboard machbar aussah und bis Mittwoch zusammenbricht, wenn zwei Engineers die halbe Woche nicht da sind, ein Ticket seinen Scope verdreifacht und drei Punkte unstated Abhängigkeiten von einem Service hatten, den das Platform-Team gerade neu schreibt.

Die Lösung ist einfach und wird fast nie umgesetzt: Kapazität committen, bevor man Arbeit committet. Die folgende Vorlage öffnet deshalb mit einem Kapazitäts-Review.

Die Agenda (zum Kopieren)

Dauer: 2 Stunden für einen 2-Wochen-Sprint; 1 Stunde für einen 1-Wochen-Sprint
Format: Moderiert, mit dem Backlog sichtbar für das ganze Team

Abschnitt 1 – Sprint-Ziel (10 min)

Ein Satz: Wie sieht ein erfolgreicher Sprint von außen aus?
Das Ziel sollte so spezifisch sein, dass jedes Teammitglied am Sprint-Ende beurteilen kann, ob es erreicht wurde
Ziele ablehnen, die nur eine Ticket-Liste sind („Auth-Refactor und Billing-Seite fertig") – das ist ein Backlog, kein Ziel

Abschnitt 2 – Kapazitäts-Review (15 min)

Jedes Teammitglied namentlich auflisten
Für jedes: geplante Urlaubszeit, On-Call-Rotation, wiederkehrende Meetings, bekannte externe Verpflichtungen
Kapazität als verfügbare Story Points oder Tage ausdrücken – nicht als Headcount
Diese Zahl ist die Obergrenze; nie mehr Arbeit auswählen als sie trägt

Abschnitt 3 – Backlog-Auswahl (45 min)

Höchstpriorisierte Punkte aus dem verfeinerten Backlog durchgehen
Für jeden Kandidaten: Hat das Team genug, um damit zu starten, oder gibt es offene Fragen, die vor Sprint-Start beantwortet werden müssen? Offene Fragen gehören in die Refinement-Queue, nicht in den Sprint
Aufhören bei 80 % der Kapazität; die verbleibenden 20 % fangen Überhang und ungeplante Arbeit auf

Abschnitt 4 – Akzeptanzkriterien (20 min)

Für jeden ausgewählten Punkt: das Kriterium nennen, das ihn als „fertig" definiert
Wenn das Team ein Kriterium nicht in 60 Sekunden nennen kann, ist das Ticket nicht verfeinert genug – zurück ins Backlog
Jetzt im Raum in das Ticket schreiben; nicht auf „wir ergänzen es später" verlassen

Abschnitt 5 – Risiken und Abhängigkeiten (15 min)

Was könnte die Lieferung des Sprint-Ziels blockieren, das das Team nicht kontrolliert?
Den Dependency-Owner nennen; jetzt die Oberfläche schaffen, solange noch Zeit ist, es vor mid-Sprint zu lösen
Nicht gelöste Abhängigkeiten bekommen einen genannten Owner aus dem Team, der sie trackt

Abschluss (15 min)

Bestätigen, dass das Sprint-Ziel angesichts der ausgewählten Arbeit noch gültig ist
Mitschreiber für das Sprint-Recap zuweisen oder automatisches Bericht-Setup bestätigen
Nächstes Planning-Datum bestätigen

Was die meisten Sprint-Planning-Vorlagen verpassen

Die beliebtesten Sprint-Planning-Vorlagen konzentrieren sich auf Backlog-Grooming und Definition-of-Done. Beides ist wichtig. Keines adressiert den Planning-Fehler, der die meisten Sprint-Misserfolge produziert: Arbeit auswählen, ohne die Verfügbarkeit zu prüfen.

Ein Team von fünf Engineers bei voller Kapazität hat ungefähr 200 Story Points pro 2-Wochen-Sprint verfügbar. Ein Team von fünf mit zwei Engineers im Urlaub, einem in der On-Call-Rotation und einem in einem dreitägigen Offsite hat vielleicht 110. Wenn im zweiten Sprint 180 Punkte ausgewählt werden, ist das Sprint bereits gescheitert. Der Auswahlschritt ist der Punkt, wo das Übercommitment passiert, und die Kapazität muss ihm vorausgehen.

Die zweite Lücke sind Akzeptanzkriterien. Teams gehen beim Planning schnell vor und beabsichtigen, Kriterien später zu schreiben. Später passiert nicht mit derselben Spezifität. Die Person, die im Raum ein präzises Kriterium geschrieben hätte, schreibt am nächsten Tag etwas Vageres aus dem Gedächtnis – oder schreibt es gar nicht. Mid-Sprint-Streitigkeiten darüber, was „fertig" bedeutet, lassen sich fast immer auf übersprungene Akzeptanzkriterien im Planning zurückführen.

Die kumulativen Kosten dieser Lücken – überlastete Sprints, mid-Sprint-Entdeckungen, neu diskutierte Definitionen – zeigen sich klar, wenn man sie zusammenzählt: The Meeting Tax.

Warum Sprint-Planning-Notizen schwieriger sind als sie aussehen

Sprint-Planning generiert mehr Informationen als fast jedes andere wiederkehrende Meeting: das Sprint-Ziel, Kapazitätszahlen, Punkt-für-Punkt-Auswahlbegründungen, Akzeptanzkriterien pro Ticket, Dependency-Owner, Risiko-Punkte. Ein nützliches Recap zu schreiben erfordert, all das in einer Form zu erfassen, die drei Tage später noch nützlich ist, wenn jemand fragt: „Warum haben wir diesen Punkt rausgeschmissen?"

Pavleur erstellt den Sprint-Planning-Bericht automatisch am Ende des Gesprächs. Es erfasst das Sprint-Ziel, das ausgewählte Backlog mit Begründung, Akzeptanzkriterien wie im Meeting genannt und Dependency-Owner wie namentlich erwähnt. Wenn jemand das Backlog oder die Kapazitätstabelle geteilt hat, ist das Visual mit der Diskussion im Bericht enthalten – Kontext, den audio-only Tools wie Otter oder Fireflies komplett verpassen würden. Jeder, der zu spät eingestiegen ist oder mid-Sprint eine Entscheidung prüfen muss, hat das vollständige Protokoll. Für einen Vergleich, wie das mit audio-only Tools verglichen werden kann: Pavleur vs. Alternativen.

Mit dem mid-Sprint-Plan-Änderung umgehen

Der Sprint-Plan ist ein Commitment, kein Vertrag. Wenn etwas mid-Sprint den Plan wirklich invalidiert – ein Production-Incident, eine kritische Abhängigkeit, die drei Tickets blockiert, eine Prioritätsverschiebung durch das Management – ist die richtige Antwort ein kurzes Re-Planning-Meeting, kein stilles Scope-Drop. Das Re-Planning dauert 20 Minuten und produziert ein aktualisiertes Sprint-Ziel, das die Realität widerspiegelt. Die Alternative ist ein Sprint, der auf dem Papier scheitert, aber informell angepasst wurde auf eine Weise, die niemand notiert hat, was die Retrospektive schwieriger macht und Velocity-Zahlen bedeutungslos.

Die Gewohnheit expliziten Re-Plannings aufbauen. Dieselbe Struktur verwenden: aktualisierte Kapazität, überarbeitete Auswahl, neu formuliertes Ziel. Das dauert weit weniger als die Verwirrung, die es verhindert.