Retrospektive-Vorlage herunterladen
Druck sie für die Wand aus oder bearbeite sie in dem Tool, das du schon nutzt. Kostenlos, ohne E-Mail und ohne Registrierung. Die Dateien sind auf Englisch.
Eine agile Retrospektive ist ein kurzes, regelmäßiges Meeting, in dem ein Team auf einen Arbeitsabschnitt zurückblickt, meist einen Sprint, und sich darauf einigt, was es an seiner Arbeitsweise ändert. In der Planung geht es darum, was das Team baut; in der Retrospektive darum, wie es baut. Am Ende steht keine Liste von Beschwerden, sondern eine oder zwei konkrete Änderungen, die das Team bis zur nächsten Retrospektive ausprobiert.
Retrospektiven gehen direkt auf das Agile Manifest von 2001 zurück. Dessen letztes Prinzip verlangt, dass Teams in regelmäßigen Abständen überlegen, wie sie effektiver werden, und ihr Verhalten dann anpassen. In Scrum schließt die Sprint Retrospective jeden Sprint ab.
Dieser Leitfaden zeigt die fünf Phasen einer guten Retrospektive, wie sich die gängigsten Formate unterscheiden, und ein durchgespieltes Beispiel, in dem ein Team von Haftnotizen zu genau einer verbindlichen Änderung mit einer verantwortlichen Person kommt.
Kurz gesagt
Eine Retrospektive hat ihren Zweck erfüllt, wenn das Team mit einer konkreten Änderung, einer verantwortlichen Person und einem Weg geht, um zu prüfen, ob es funktioniert hat. Alles andere im Meeting dient nur dazu, diese eine Änderung zu finden.
Die Prime Directive
Die meisten Retrospektiven beginnen damit, die Retrospective Prime Directive zu wiederholen, die Norm Kerth in Project Retrospectives (2001) formuliert hat. Kurz gesagt: Was auch immer wir herausfinden, wir gehen davon aus, dass alle ihr Bestes gegeben haben, mit dem Wissen, den Fähigkeiten, den Mitteln und der Situation, die sie damals hatten.
Es geht dabei nicht um Höflichkeit. Ein Team, das mit Schuldzuweisungen rechnet, gibt sicheres, allgemeines Feedback und verschweigt die eigentliche Ursache. Erst wenn Schuld vom Tisch ist, sagt jemand laut: „Ich wusste nicht, dass sich die Spezifikation geändert hatte“, und mit genau so einem Satz beginnt meist der nützliche Teil des Meetings.
Die fünf Phasen einer Retrospektive
Esther Derby und Diana Larsen beschreiben in ihrem Buch Agile Retrospectives fünf Phasen, denen fast jede gute Retrospektive folgt, egal welches Format sie nutzt:
| Phase | Zweck | Typische Dauer in einer 45-Minuten-Retro |
|---|---|---|
| 1. Rahmen setzen | Ziel und Prime Directive wiederholen; alle früh zu Wort kommen lassen | 5 Minuten |
| 2. Daten sammeln | Festhalten, was passiert ist: Fakten, Ereignisse und wie es sich angefühlt hat | 10 Minuten |
| 3. Erkenntnisse gewinnen | Daten gruppieren, das größte Thema auswählen und seine Ursache finden | 15 Minuten |
| 4. Entscheiden, was zu tun ist | Eine oder zwei Änderungen wählen, jede mit einer verantwortlichen Person | 10 Minuten |
| 5. Abschließen | Die Zusagen bestätigen und prüfen, wie das Meeting lief | 5 Minuten |
Am häufigsten überspringen Teams die dritte Phase. Wer direkt von „Hier sind unsere Haftnotizen“ zu „Hier sind unsere Maßnahmen“ springt, bekommt Maßnahmen, die nur Symptome behandeln.
Gängige Retrospektive-Formate
Das Format ist die Auswahl an Fragen, die du in Phase 2 stellst. Wer die Formate wechselt, verhindert, dass eine regelmäßige Retrospektive zur Routine wird.
| Format | Fragen | Gut für |
|---|---|---|
| Start, Stop, Continue | Was sollten wir anfangen, aufhören und beibehalten? | Neue Teams; schnelle Retros |
| Starfish | Beibehalten, mehr davon, weniger davon, aufhören, anfangen | Teams, die mehr Nuancen wollen als „gut“ und „schlecht“ |
| Mad, Sad, Glad | Was hat dich geärgert, enttäuscht oder gefreut? | Sprints, die emotional schwierig waren |
| 4Ls | Liked, Learned, Lacked, Longed for | Ende eines Projekts oder Quartals |
| Segelboot | Wind (was geholfen hat), Anker (was uns gebremst hat), Felsen (Risiken voraus) | Teams vor einer riskanten Phase |
| Zeitstrahl | Die wichtigsten Ereignisse des Sprints auftragen, dann Hochs und Tiefs markieren | Nachbetrachtungen nach Vorfällen oder Releases |
Der Starfish, meist Patrick Kua zugeschrieben, ist das Format unserer kostenlosen Retrospektive-Vorlage. Seine fünf Kategorien lassen Platz für „das funktioniert, aber wir übertreiben es“, was bei einer einfachen Aufteilung in gut und schlecht verloren geht.
Ein durchgespieltes Retrospektive-Beispiel
Hier eine 45-minütige Retrospektive eines fiktiven Produktteams mit sieben Personen. Ihr zweiwöchiger Sprint endete damit, dass eine Exportfunktion für Kunden drei Tage zu spät ausgeliefert wurde.
Phase 1: Rahmen setzen (5 Minuten)
Die Moderation wiederholt die Prime Directive und nennt das Ziel: „Wir haben den Export drei Tage zu spät ausgeliefert. Lasst uns herausfinden, warum, und uns auf eine Änderung für den nächsten Sprint einigen.“ Alle fassen den Sprint in einem Wort zusammen. Zwei sagen „gehetzt“.
Phase 2: Daten sammeln (10 Minuten)
Das Team erstellt einen kurzen Zeitstrahl des Sprints und schreibt dann fünf Minuten lang still Starfish-Notizen, damit nicht die lauteste Stimme die Agenda bestimmt.
| Beibehalten | Mehr davon | Weniger davon | Aufhören | Anfangen |
|---|---|---|---|---|
| Daily Stand-ups unter 15 Minuten | Pairing bei kniffligen Stories | Spontane Design-Reviews im Chat | Akzeptanzkriterien mitten im Sprint ändern | Designs dem Kunden vor dem Sprint zeigen |
| Tests vor dem Merge schreiben | Demos für den Kunden | Status-Meetings, die eine Nachricht sein könnten | Stories ohne finales Mockup beginnen |
Phase 3: Erkenntnisse gewinnen (15 Minuten)
Das Team gruppiert die Notizen und stimmt ab. Der mit Abstand größte Cluster betrifft Anforderungen, die sich nach Sprintbeginn geändert haben. Das Team wendet die 5-Why-Methode darauf an:
- Warum kam der Export zu spät? Beim Testen zeigte sich, dass er nicht den Erwartungen des Kunden entsprach.
- Warum? Die Akzeptanzkriterien haben sich am sechsten Tag des Sprints geändert.
- Warum? Die Betriebsleiterin des Kunden hat das Design am fünften Tag zum ersten Mal gesehen.
- Warum? Designs werden intern geprüft, aber dem Kunden nicht gezeigt, bevor eine Story in den Sprint geht.
- Warum? Niemand ist für die Freigabe durch den Kunden zuständig. Das Produktteam ging davon aus, dass das Account Management sich darum kümmert, und das Account Management ging vom Produktteam aus.
Die eigentliche Ursache ist nicht „Kommunikation“. Es ist ein Schritt im Prozess, für den niemand verantwortlich ist.
Phase 4: Entscheiden, was zu tun ist (10 Minuten)
Jemand schlägt vor, „besser mit dem Kunden zu kommunizieren“. Die Moderation widerspricht: Das ist ein Wunsch, keine Änderung. Das Team einigt sich stattdessen auf ein Experiment:
- Änderung: In den nächsten zwei Sprints braucht jede Story mit einer für Kunden sichtbaren Änderung ein vom Kunden geprüftes Mockup, bevor sie in den Sprint geht.
- Verantwortlich: die Produktmanagerin.
- Woran wir es merken: Wir zählen die Stories, deren Akzeptanzkriterien sich nach Sprintbeginn ändern. Im letzten Sprint waren es drei.
Die übrigen Notizen kommen auf eine Liste, um später darauf zurückzukommen. Das Team verpflichtet sich zu einer Änderung, nicht zu sieben.
Phase 5: Abschließen (5 Minuten)
Die Moderation liest das Experiment und die verantwortliche Person noch einmal vor, und alle bewerten die Retrospektive auf einer Skala von eins bis fünf. Die nächste Retrospektive beginnt damit, die Zahl zu prüfen.
Woran Retrospektiven scheitern
- Keine Maßnahme oder zu viele. Eine Liste mit zehn Verbesserungen gehört niemandem. Wähle eine oder zwei.
- Maßnahmen, die Wünsche sind. „Besser kommunizieren“ lässt sich am Montag nicht umsetzen. „Der Kunde gibt Mockups vor dem Sprint frei“ schon.
- Die letzte Maßnahme nie überprüfen. Wenn die nächste Retrospektive nicht mit einem Blick auf die letzte Änderung beginnt, lernt das Team, dass Zusagen optional sind.
- Schuldzuweisungen. Sobald eine Person herausgegriffen wird, wägen alle anderen ab, was sie sagen.
- Jedes Mal dasselbe Format. Wechsle die Fragen, damit das Team nicht auf Autopilot dieselben Antworten gibt.
Retrospektiven ganz ausfallen zu lassen, hat seinen eigenen Preis. Mehr dazu in die Kosten von Prozessschulden.
Retrospektive vs. Sprint Review vs. Post-Mortem
Diese drei werden oft verwechselt, weil alle zurückblicken:
- Sprint Review: Das Team zeigt Stakeholdern, was es gebaut hat, und holt Feedback zum Produkt ein.
- Retrospektive: Das Team schaut, wie es gearbeitet hat, und ändert seinen Prozess. Stakeholder sind meist nicht dabei.
- Post-Mortem: eine einmalige Nachbetrachtung eines bestimmten Vorfalls oder Fehlers. Sie nutzt oft dieselben Phasen, mit einem Zeitstrahl im Mittelpunkt.
Kostenlose Retrospektive-Vorlage
Die kostenlose Retrospektive-Vorlage gibt es als PDF, Word-Dokument, Excel-Arbeitsmappe und PowerPoint-Präsentation. Sie nutzt das Starfish-Format, mit Fragen zu jeder der fünf Kategorien und einem Maßnahmen-Tracker für Verantwortliche und Termine.
Mehr zu Retrospektiven
- So moderierst du eine Projekt-Retrospektive: die Haltung der Moderation und wie du mit einem aufgeheizten Raum umgehst.
- So führst du eine Sprint-Retrospektive in Microsoft Teams durch: ein 45-Minuten-Playbook für Remote-Teams.
- Die Kosten von Prozessschulden: warum ausgelassene Retrospektiven Teams bremsen.
Häufige Fragen
Wie oft sollte ein Team eine Retrospektive machen?
Am Ende jedes Sprints oder, bei Teams ohne Sprints, alle zwei bis vier Wochen. Üblich ist auch eine Retrospektive nach einem großen Release oder einem Vorfall.
Wie lange sollte eine Retrospektive dauern?
Etwa 45 Minuten für einen zweiwöchigen Sprint. Der Scrum Guide begrenzt die Sprint Retrospective bei einem einmonatigen Sprint auf drei Stunden und merkt an, dass sie bei kürzeren Sprints meist kürzer ist.
Wer sollte an einer Retrospektive teilnehmen?
Die Menschen, die die Arbeit gemacht haben: das Umsetzungsteam, in Scrum einschließlich Product Owner und Scrum Master. Führungskräfte und Stakeholder bleiben meist draußen, damit alle offen sprechen können.
Wer sollte eine Retrospektive moderieren?
Oft der Scrum Master oder ein wechselndes Teammitglied. Der Wechsel hilft, und bei einer angespannten Retrospektive kann eine externe Moderation den Raum auf den Prozess statt auf Personen fokussieren.
Was ist das Ergebnis einer Retrospektive?
Eine oder zwei konkrete Prozessänderungen, jede mit einer verantwortlichen Person und einem Weg, in der nächsten Retrospektive zu prüfen, ob sie funktioniert hat.
Bereit für die Praxis? Probier es mit deinem Team und der kostenlosen Retrospektive-Vorlage aus.
