Was vorher fertig sein muss
Der aktuelle Sprint ist mit Review und Increment-Demo abgeschlossen, sodass konkrete Erfahrungen vorliegen.
Psychologische Sicherheit ist etabliert oder wird in der Session explizit eingefordert, sodass kritische Punkte geaeussert werden koennen.
Was vor Start vorliegen muss
Miro- oder FigJam-Board mit Vorlage (z. B. Mad-Sad-Glad, Sailboat, Start-Stop-Continue); Timer; Aktionsboard fuer Massnahmen mit Owner und Frist; Liste der Action Items aus der Vorgaenger-Retro.
Ein Facilitator (rotierend oder Scrum Master); alle Entwicklungsteam-Mitglieder; optional Product Owner; kein externer Stakeholder ohne Einladung.
Sprint-Burndown, Velocity, abgeschlossene und nicht abgeschlossene Items; Major-Incidents im Sprint; Status der vorherigen Action Items; geteilte Vorab-Stimmung (Pulscheck).
60-90 min pro 2-Wochen-Sprint
Format pro Retro variieren, um Routine zu vermeiden. Vorgaenger-Action-Items sichtbar machen. Regeln ansagen: Vegas-Regel (was hier gesagt wird, bleibt hier), Fokus auf System statt Personen, eine Aktion lieber als zehn.
Die eine Frage, die diese Methode beantwortet
Welche eine Veraenderung am Prozess oder System verbessert den naechsten Sprint am staerksten, und wer setzt sie verbindlich um?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Set the Stage | 5-10 min | Ziel der Retro nennen, Regeln wiederholen, Pulse-Check (Daumen oder 1-5). Action Items aus Vorperiode kurz reviewen: erledigt, offen, fallen gelassen. | Wenn aus drei Retros hintereinander dieselben Action Items unerledigt sind, ist das das einzig sinnvolle Thema dieser Retro. |
2Phase 2: Gather Data | 15-20 min | Format-spezifische Sammlung: Mad-Sad-Glad, Was lief gut/schlecht, 4Ls, Sailboat. Stilles Schreiben zuerst, dann Cluster. Auch Metriken einbeziehen (Velocity, Bug-Anzahl, Incident-Count). | Wenn alle in einem Format dieselbe Phrase wiederholen, ist Themenbreite zu eng. Format wechseln oder Frage neu stellen, sonst wird die Retro Pflichtuebung. |
3Phase 3: Generate Insights | 15-20 min | Top-Themen voten (Dot-Voting, 2-3 Punkte pro Person). Beim Top-Thema 5 Whys oder Fishbone, um Ursache zu finden. Maximal zwei Themen tief bearbeiten. | Lieber ein Thema mit Tiefe als fuenf oberflaechlich. Wenn alles wichtig ist, wird nichts geaendert. |
4Phase 4: Decide What to Do | 15-20 min | Pro Top-Thema eine Massnahme: SMART formuliert, mit Owner, Frist und Erfolgsindikator. Maximal zwei bis drei Action Items pro Retro. | Action Item ohne Owner ist Wunsch. Owner muss anwesend sein und „ja“ sagen, sonst nicht in die Liste. Erfolgsindikator naechste Retro pruefbar. |
5Phase 5: Close the Retro | 5 min | Plus-Delta oder Round Robin: was war an dieser Retro hilfreich, was beim naechsten Mal anders. Action Items zusammenfassen, Verantwortung bestaetigen. | Schliessung ist nicht „und tschuess“. Wenn der Retro-Wert nicht klar ist, sinkt Engagement der naechsten. Plus-Delta liefert die Verbesserungs-Schleife fuer die Retro selbst. |
Was am Ende rauskommt
Retro-Dokumentation mit Sprint-ID, Teilnehmenden, gesammelten Themen (Cluster und Stichpunkte), Top-Insights mit Ursachenanalyse, Action Items (Beschreibung, Owner, Frist, Erfolgsindikator), Plus-Delta-Notizen.
Pro Sprint ein Eintrag mit Datum und Sprint-ID. Action Items mit eindeutiger ID, Status (offen, in Arbeit, erledigt, fallen gelassen) ueber Retros hinweg verfolgen. Quartals-Review der Action-Item-Quote als Meta-Indikator.
Kompakte Arbeitsvorlage für Sprint Retrospective mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Sprint Retrospective Arbeitsvorlage
## Ziel
Scrum Event, um Zusammenarbeit, Qualität und Prozess zu inspizieren und anzupassen.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Improvement Actions:
- Team Agreements:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Sprint Retrospective - Plattform-Team Workspot, Sprint 47 (KW 17-18)
**Teilnehmende**: 6 Engineers, 1 PO, 1 Scrum Master.
**Vorgaenger-Action-Items**
- AI-46-01: Definition of Done um Performance-Check erweitern. Status: erledigt (PR #2841).
- AI-46-02: Code-Review SLA 24 h. Status: offen, wird in diese Retro mitgenommen.
**Gather (Format Sailboat)**
- Wind: Pair-Programming-Sessions Di/Do haben Wissensluecken geschlossen.
- Anker: Code-Reviews dauern >48 h, Items haengen in Review.
- Felsen: Externes Audit-Team blockiert Auth-Migration.
- Insel: 95.-Perzentil Lead Time unter 10 Tage.
**Top-Insight**: Reviewer-Kapazitaet ist Engpass. 5-Whys: aktuelle Sprint-Belastung ist 9.5 Items pro Person, Reviewer haben keine geblockte Zeit.
**Action Items**
- AI-47-01: Tagliche Review-Slot 14:00-15:00, Owner @lisa, ab Sprint 48. Indikator: 85.-Perzentil Review-Wartezeit unter 12 h.
- AI-47-02: WIP-Limit „In Review“ auf 3 herabsetzen, Owner @ben, ab Sprint 48. Indikator: kein Karten-Stau in 3 aufeinanderfolgenden Daily-Stand-ups.
**Plus-Delta**: Plus: konkrete Massnahme mit Indikator. Delta: Vorgaenger-Action-Items frueher reviewen.Symptome erkennen, gegensteuern
Team kommt mit den gleichen Stichworten, Energie ist niedrig.
Format variieren (Sailboat, 4Ls, Mad-Sad-Glad, Lean Coffee). Externes Facilitator-Augenpaar gelegentlich einsetzen. Zeitfenster strecken statt verkuerzen.
Sieben Massnahmen werden beschlossen, beim naechsten Sprint sind zwei erledigt, fuenf liegen brach.
Maximal drei Action Items, lieber eine mit grosser Wirkung. Items ohne anwesenden Owner ablehnen. Erledigungsquote als Meta-Indikator beobachten.
„X war zu langsam“ oder „Y hat den Bug nicht gesehen“ steht auf den Karten.
Facilitator formuliert um: was im System hat den Fehler erlaubt. Personen-Aussagen werden in Prozess- oder Tool-Aussagen ueberfuehrt. Sonst kippt psychologische Sicherheit.
„Wir verbessern Reviews“ ohne messbare Definition. In drei Sprints unklar, ob es geklappt hat.
Indikator pflicht. Was waere ein Beweis fuer Erfolg in 1-2 Sprints. Wenn nicht definierbar, Action Item neu schneiden.
Manager oder Kunde sitzt dabei, Team schweigt zu heiklen Themen.
Retro ist Team-Event. Externe nur bei expliziter Einladung und Themenrelevanz. Falls Eskalation noetig, separate Session danach.
Items aus drei Retros sind offen, niemand spricht es an.
Erster Tagesordnungspunkt: Status Vorgaenger-Items. Wenn drei Sprints offen, ist das einzige Retro-Thema „warum schliessen wir keine Action Items“.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.