Sprint Retrospective: Komplettguide — 24 Retro-Aktivitäten & Spiele + Agenda-Vorlage

Die Sprint Retrospective ist die Auswertung, die ein Scrum-Team am Ende jedes Sprints abhält, um zu prüfen, wie die Arbeit lief — was gut lief, wo es hakte und welche eine Sache im nächsten Sprint verbessert wird. Sie bewertet „wie wir arbeiten"; das Sprint Review bewertet „was wir gebaut haben".

Die 30-Sekunden-Version

Frequenz: einmal am Ende jedes Sprints, direkt nach dem Sprint Review;

Dauer: Zwei-Wochen-Sprint → 60–90 Minuten; Ein-Wochen-Sprint → 45 Minuten;

Ergebnis: 1–2 Verbesserungsaktionen mit namentlich Verantwortlichem und überprüfbarem Abschlusskriterium (kein Stapel von „nächstes Mal einfach aufmerksamer");

Gesundheitssignal: Sind die Aktionen aus drei Retrospectives in Folge tatsächlich gelandet, verbessert sich der Prozess wirklich.

Standard-Agenda (60-Minuten-Version)

Zeit	Abschnitt	Zweck
0:00–0:05	Eröffnung und Warmwerden	Ton setzen: sicher, Sachebene statt Personenebene
0:05–0:15	Daten sammeln	Alle notieren Fakten und Gefühle des Sprints (mit den Aktivitätsrahmen unten)
0:15–0:30	Erkenntnisse bilden	Clustern und abstimmen; die 1–3 wichtigsten Themen herausheben
0:30–0:50	Aktionen beschließen	Themen in konkrete Aktionen übersetzen: wer macht was, wann ist sie fertig
0:50–0:60	Abschluss	Die Aktionen des letzten Meetings prüfen, die diesjährigen aufs Board bringen

Das größte Versagensmuster der Retrospective ist nicht betretenes Schweigen — es ist „great Diskussion, niemand verfolgt die Aktionen". Aktionen gehören auf das Sprint-Board und werden wie jedes andere Arbeitselement behandelt.

24 Retro-Aktivitäten & Spiele

A. Klassische Rahmen (für den täglichen Wechsel ausreichend)

Start / Stop / Continue: was anfangen, was lassen, was weiterführen. Am einfachsten und universellsten, passt zu jedem Team;

4Ls: Liked, Learned, Lacked, Longed for;

Mad / Sad / Glad: emotionsgetrieben, gut, um Stimmungsprobleme aufzudecken;

Segelboot (Sailboat): Wind = Rückenwind, Anker = Widerstand, Felsen = Risiken, Insel = Ziel. Sehr visuell; passt zu Projektmeilensteinen;

KPT: Keep / Problem / Try; bei japanisch geprägten Teams verbreitet, klare Struktur.

B. Qualitätsspezifische Aktivitäten

Defect-Map: die Defects des Sprints nach Modulen an die Wand klustern und die Katastrophengebiete mit bloßem Auge suchen; besprechen, ob es ein Design- oder ein Prozessproblem ist;

Rework-Zeitachse: jede unterbrochene oder doppelt gemachte Aufgabe auflisten und die Ursache hinterfragen (unklare Anforderungen? instabile Umgebung? Berichte ohne Kontext?);

Ein unvergesslicher Bug: jeder erzählt den absurdesten Defect des Sprints und seine Ursache — deutlich wirksamer als abstrakte Diskussion.

C. Icebreaker zur Auflockerung (die Kategorie „Retro-Games")

Zwei Wahrheiten, eine Lüge: jeder nennt drei Dinge, die diesen Sprint passiert sind, eines davon falsch; die anderen raten;

Emoji-Wetterbericht: den eigenen Sprint mit Emojis zusammenfassen;

Roulette-Sprecher: die nächste Sprechperson zufällig ziehen, damit nicht immer dieselben reden;

Zeitmaschine: vorstellen, in einem Jahr auf das heutige Projekt zurückzublicken, und einen Brief an das jetzige Team schreiben.

D. Ursachenjäger

5 Why: zum am stärksten gewählten Problem fünf Mal hintereinander „warum" fragen;

Ishikawa-Diagramm: Ursachen entlang von Menschen, Prozess, Werkzeugen und Umgebung zuordnen;

Pre-Mortem: annehmen, der nächste Sprint sei gescheitert; vorab den „Scheiterbericht" schreiben und rückwärts ableiten, was zu verhindern ist.

E. Für Remote-Teams

Online-Whiteboard-Stickies: das klassische Drei-Spalten-Board (FunRetro / EasyRetro / Miro), anonyme Notizen + Abstimmung;

Stillschreiben, dann diskutieren: erst 3 Minuten alleine schreiben, dann die Punkte durchgehen — verhindert die Prägung durch die erste Sprechperson;

Heat-Voting: jeder hat 3 Stimmen für die Stickies, über die er am meisten sprechen will; nur die Top 2 kommen in die Diskussion;

Gestaffelt und gruppiert: große Teams zuerst in Breakout-Rooms diskutieren, dann zusammenführen und berichten.

F. Varianten gegen Routine

Sprint benoten: den Sprint mit 1–10 bewerten und erklären, warum es keine höhere Note ist;

Zielcheck: das Sprint Goal anpinnen und besprechen, was jede Arbeit tatsächlich zum Ziel beitrug;

Rollenwechsel: Entwickler sprechen für den PO, der PO für die QA — je 2 Minuten;

Dankesrunde: jeder dankt öffentlich einem Kollegen für eine konkrete Hilfe; guter Abschluss, stärkt die Stimmung;

Mikroexperimente: Aktionen als Experimente verpacken: „diesen Sprint X ausprobieren, bei der nächsten Retrospective anhand der Daten entscheiden, ob es bleibt." Weniger Verpflichtungsdruck, leichter zu landen.

Wie man Aktionen schreibt, die niemand vergisst

Schlecht	Gut
„Testen verstärken"	„Vor jedem Release die Checkliste durchgehen, ausgeführt von der Bereitschafts-QA der Woche; Erfüllungsquote bei den nächsten zwei Retrospectives prüfen"
„Unnötige Kommunikation reduzieren"	„Bug-Reports laufen nur über das gemeinsame Register; im Chat nur den Link posten, ohne das Problem zu beschreiben; Stichprobe nächsten Mittwoch"
„Codequalität verbessern"	„Pre-Commit-Lint-Hook einführen, vom Backend-Lead bis diesen Freitag konfiguriert"

Gemeinsam: namentlich Verantwortlicher, Frist und überprüfbares Abschlusskriterium.

Die Retrospective mit Daten stützen, nicht mit Eindrücken

„Die Qualität dieses Sprints war schlecht" — solche Eindruckskonclusionen erzeugen nur Rechtfertigungen. Sprechen Sie mit quantifizierten Daten:

Defect-Gesamtzahl des Sprints, nach Modul und Schweregrad;

Durchschnittliche Behebungszeit je Defect, Anzahl der Rückfragen;

Herkunft der Defects (internes Testing / Beta-Nutzer-Reports / Produktions-Reports).

Diese Zahlen brauchen ein einheitliches Defect-Register — keine Archäologie in Chatverläufen. BugCapturer-Berichte kommen mit Screenshot-Annotationen und Console-/Network-Fehlern an (siehe Diagnosefunktion) und werden automatisch in einen Slack / Microsoft Teams-Kanal gepusht — ein einziger Nachverfolgungspunkt. Nach Modul/Schweregrad/Status gepivott fallen die Zahlen oben heraus — vor der Retrospective eine Tabelle exportieren, und das Material für die Defect-Map (Aktivität 6) und die Rework-Zeitachse (Aktivität 7) steht bereit.

FAQ

F: Was ist der Zweck einer Sprint Retrospective? A: Die Arbeitsweise des Teams kontinuierlich verbessern. Der Scrum Guide sagt es klar: das Ergebnis ist ein ausführbarer Verbesserungsplan, kein bloßer Gefühlsausdruck. F: Retrospective vs. Review — was ist der Unterschied? A: Das Review präsentiert den Produktinkrement den Stakeholdern; die Retrospective prüft den Zusammenarbeitprozess (nur das Team). Beides ist nötig; nicht zusammenlegen. F: Bei nur 3 Leuten — lohnt sich eine Retrospective trotzdem? A: Ja — auf 30 Minuten kürzen: 5 Minuten sammeln, 10 abstimmen, 15 Aktionen festlegen. Kleine Teams können Prozesse schneller ändern, der Nutzen ist also sogar größer. F: Immer wieder dieselben Probleme. Was tun? A: Dann landen Aktionen nicht oder haben keinen Verantwortlichen. Die nächste Retrospective beginnt damit, die Erfüllungsquote der letzten Aktionen öffentlich zu prüfen; notfalls „Verbesserungsaktionen landen" in die Definition of Done aufnehmen. F: Zu viele Beschwerden, die Stimmung ist gedrückt — was tun? A: Immer mit etwas Positivem abschließen: Dankesrunde oder Sprint-Note. Und sicherstellen, dass jede Retrospective mindestens eine „Weiter so"-Konclusion erzeugt — eine Retrospective ist kein Prügelprozess.

Browser-Erweiterung

Web-SDK einbetten

Link teilen

Automatischer Kontext

Teams & Mitglieder

Projekte & Domains