Sprint-Retrospektiven-Vorlage für Engineering-Teams

Warum die meisten Retros keine Veränderung bewirken

Sprint-Retrospektiven haben ein strukturelles Problem, das Vorlagen nicht lösen: Teams generieren Verbesserungsideen, überprüfen sie aber nicht. Die Retro produziert fünf Action Items. Die nächste Retro beginnt auf einem leeren Blatt. Dieselben Probleme tauchen wieder auf.

Die folgende Vorlage baut die Überprüfung in den Einstieg ein, sodass sie nicht übersprungen werden kann. Allein diese eine Änderung tut mehr für die Effektivität von Retros als jede Formatanpassung.

Die Agenda (zum Kopieren)

Dauer: 60 Minuten für einen 2-Wochen-Sprint; 45 Minuten für einen 1-Wochen-Sprint
Format: Moderiert, mit einem geteilten Async-Board (Miro, FigJam, Notion – nach Wahl des Teams)

Abschnitt 1 – Action-Item-Review (10 min)

Action Items des letzten Sprints einzeln vorlesen
Jeden Punkt kennzeichnen: Erledigt / In Arbeit / Verworfen (kurzer Grund für Verworfene)
Unvollständige Punkte für diesen Sprint vormerken; jetzt nicht nochmals diskutieren

Abschnitt 2 – Daten-Snapshot (5 min)

Sprint-Velocity vs. Ziel
Ungeplante Arbeit, die mehr als einen Tag überschritten hat
Incidents oder On-Call-Ereignisse
Scope-Änderungen mid-Sprint
Daten auf dem Bildschirm zeigen, noch ohne Diskussion

Abschnitt 3 – Was gut lief (10 min)

Team trägt Punkte async vor dem Meeting ein oder in den ersten 3 Minuten
Top 2–3 diskutieren; offensichtliche Einigkeit überspringen
Keine Zeit für Dinge verschwenden, die nicht umsetzbar sind

Abschnitt 4 – Was verbessert werden kann (15 min)

Gleiches Format: Async-Input, Punkte mit dem höchsten Signal diskutieren
Für jeden Punkt: Einmaliges Ereignis oder Muster? Nur Muster werden zu Action Items
Aufgabe des Moderators: „Das war frustrierend" in etwas Konkretes und Veränderbares umwandeln

Abschnitt 5 – Action Items (15 min)

Jeder Punkt muss haben: Beschreibung, einen Owner (nicht „das Team"), Fälligkeitsdatum
Maximal 2–3 Punkte anstreben; mehr verwässert die Accountability
Unvollständige Punkte aus Abschnitt 1 vormerken

Abschluss (5 min)

Kurzes +/-/Delta zur Retro selbst
Bestätigen, dass das Recap noch heute rausgeht

Was gängige Retro-Formate verpassen

Start/Stop/Continue und Was lief gut/Was verbessern/Action Items sind beides valide Formate. Das Problem ist nicht das Format – es ist, dass Vorlagen den Review-Schritt am Anfang selten einbauen. Dieser Schritt ist das Einzige, was Accountability-Kontinuität von einer Retro zur nächsten schafft. Ohne ihn ist die Retro eine Gefühlsmaschine, keine Veränderungsmaschine.

Vorlagen adressieren auch keine Zeitbox-Disziplin. „Was verbessert werden kann" läuft fast universell zu lang, weil es emotionaler ansprechender ist als „Was gut lief". Ohne harte Boxen wird aus einer 60-minütigen Retro ein 90-minütiges Gespräch mit 5 Minuten gehetzter Action Items am Ende. Die Action Items sind der einzige Teil, der wirklich etwas ändert.

Die dritte Lücke: Action Items werden als vage Direktiven formuliert. „Frontend-Backend-Kommunikation verbessern" ist kein Action Item. „Sarah setzt ab nächstem Montag einen wöchentlichen 30-minütigen Sync zwischen Frontend- und Backend-Leads auf" ist eines. Owner und Startdatum müssen im Raum genannt werden – später werden die Details weicher.

Die kumulativen Kosten dieser Muster zeigen sich Wochen später als nie erfasster Kontext und immer wieder diskutierte Entscheidungen. The Meeting Tax zeigt, wie das über ein Quartal quantitativ aussieht.

Warum Retro-Recaps schwieriger zu schreiben sind als Standup-Notizen

Standup-Recaps sind kurz. Sprint-Planning-Recaps sind strukturiert. Retrospektiven-Recaps sind schwierig, weil der Inhalt unstrukturiert ist – Sticky Notes, Diskussionen, die zwischen Abschnitten springen, ein Mix aus Gefühlen und Daten. Wer das Recap schreibt, muss einen kohärenten Faden aus einem Meeting rekonstruieren, das in mehrere Richtungen gegangen ist.

Pavleur ist genau wegen dieser Unordnung gut geeignet. Es erfasst alles, was während des Meetings gesagt wurde, und alles, was auf dem Bildschirm zu sehen war – das geteilte Board, das Velocity-Diagramm aus Abschnitt 2, das Incident-Ticket, das jemand in Abschnitt 4 referenziert hat. Der Bericht nach dem Meeting ist strukturiert, mit Action Items, die aus den tatsächlichen Entscheidungen im Raum extrahiert wurden (mit Ownern und Daten, wie genannt). Keine Rekonstruktion nötig, keine Nacharbeit nach dem Gespräch.

Audio-only Transkriptionstools erfassen die Worte, aber nicht den visuellen Kontext. In einer Retro ist das Visuelle oft das Wichtigste – das Sticky-Note-Board, das Diagramm, das ein Muster sichtbar gemacht hat, das Ticket, das eine Diskussion verankert hat. Dieser Kontext existiert in einem audio-only Recap nicht. Für einen direkten Tool-Vergleich: Pavleur vs. Alternativen.

Häufige Retro-Fehler

Dasselbe Action Item taucht in drei aufeinanderfolgenden Retros auf. Abschnitt 1 ist nicht verhandelbar. Wenn ein Punkt immer wieder nicht erledigt wird, entweder mit einem genannten Grund verwerfen oder eskalieren – nicht unbegrenzt vormerken.

Diskussion wird zum Ablassen ohne Auflösung. Die Aufgabe des Moderators in Abschnitt 4 ist es, „dieser Prozess ist kaputt" in eine konkrete, veränderbare Sache zu übersetzen. Wenn das nicht in 30 Sekunden möglich ist, kommt es auf den Parkplatz.

Niemand trägt Punkte async vor dem Meeting ein. Das Board 24 Stunden im Voraus verschicken. 2–3 Punkte als Seed eintragen, um das Leeres-Blatt-Problem zu lösen. Meetings laufen besser, wenn alle mit etwas Geschriebenem ankommen.