Sprint-Retrospektive: Formate, Fragen und Beispiele

Eine Sprint-Retrospektive ist das Meeting, in dem Teams eine Stunde lang den Liefermodus unterbrechen und offen darüber sprechen, wie sie arbeiten. Die meisten Teams planen sie ein. Weit weniger führen sie wirklich gut durch.

Was ist eine Sprint-Retrospektive?

Eine Sprint-Retrospektive ist eine wiederkehrende Scrum-Veranstaltung, die am Ende jedes Sprints stattfindet. Das Team reflektiert dabei, wie es zusammengearbeitet hat, und legt konkrete Verbesserungen für den nächsten Sprint fest. Es ist das Gespräch über „wie wir arbeiten", nicht über „was wir gebaut haben".

Der Scrum Guide definiert drei Fragen, die jede Retrospektive rahmen: Was lief gut? Was könnte verbessert werden? Und welche eine wertvolle Verbesserung verpflichtet sich das Team für den nächsten Sprint umzusetzen?

Während die Sprint-Planung die Richtung des Teams für den kommenden Sprint festlegt, schließt die Retrospektive den Kreis zum abgeschlossenen Sprint. Gemeinsam bilden sie den Verbesserungsmotor innerhalb der agilen Methodik.

Key Facts

• Die Sprint-Retrospektive ist seit der ersten Ausgabe des Scrum Guide im Jahr 1995 fester Bestandteil und eines der fünf Scrum-Events (Scrum Guide, 2020).
• „Agile Retrospectives: Making Good Teams Great" von Esther Derby und Diana Larsen (2006) kodifizierte die Fünf-Phasen-Struktur der Retrospektive, die heute von der Mehrheit der Scrum-Teams verwendet wird.
• 83 % der leistungsstarken agilen Teams berichten, dass sie regelmäßig Retrospektiven durchführen, gegenüber 52 % der leistungsschwachen Teams (State of Agile Report, 17. Ausgabe, 2023).

Sprint-Retrospektive vs. Sprint-Review

Diese beiden Meetings finden am Ende jedes Sprints statt und werden leicht verwechselt. Sie dienen jedoch völlig unterschiedlichen Zwecken.

Die Retrospektive ist für das Team. Das Review ist für das Produkt. Beide als ein Meeting zu führen ist ein häufiger Fehler, der die offene Kommunikation untergräbt: Menschen sprechen nicht ehrlich über Prozessprobleme, wenn externe Stakeholder im Raum sind.

Die 5 Phasen einer Retrospektive

Die Fünf-Phasen-Struktur von Derby und Larsen aus „Agile Retrospectives" gibt Teams einen zuverlässigen Ablauf. Jede Phase hat einen bestimmten Zweck, und das Überspringen von Phasen ist der häufigste Grund, warum Retrospektiven scheitern.

Teams, die direkt zu „Erkenntnisse gewinnen" springen, ohne zuvor Daten zu sammeln, debattieren am Ende Meinungen statt auf Fakten zu reagieren. Und Teams, die den „Abschluss" überspringen, verpassen die Chance, das Retro selbst im Laufe der Zeit zu verbessern.

Beliebte Retrospektiven-Formate

Das gewählte Format bestimmt, welches Gespräch entsteht. Hier sind die fünf am häufigsten eingesetzten Retrospektiven-Formate und wann jedes am besten passt.

Wechseln Sie das Format alle paar Sprints. Wer jedes Mal Start-Stop-Continue nutzt, bekommt dieselben Antworten von denselben Personen. Ein neues Format setzt das Gespräch neu auf.

Fragen für die Retrospektive

Gute Retrospektiven-Fragen öffnen das Gespräch, statt es zu schließen. Hier sind Impulse nach Absicht gruppiert.

Um herauszufinden, was gut lief:

• Worauf sind Sie in diesem Sprint stolz?
• Welcher Teil unseres Prozesses hat besser funktioniert als erwartet?
• Was haben wir getan, das wir schützen und nie opfern sollten?

Um Probleme ans Licht zu bringen:

• Was hat Sie in diesem Sprint am meisten ausgebremst?
• Wo haben wir das Vertrauen untereinander oder zu Stakeholdern verloren?
• Womit mussten Sie einen Umweg gehen, anstatt es direkt anzugehen?

Um Erkenntnisse zu gewinnen:

• Warum ist das passiert, und ist es schon früher passiert?
• Wenn wir eine Sache an unserer Arbeitsweise ändern würden, was hätte den größten Effekt?
• Welche Annahme haben wir getroffen, die sich als falsch herausgestellt hat?

Um Maßnahmen anzustoßen:

• Wozu verpflichten wir uns als einzige Veränderung im nächsten Sprint?
• Wer ist für diese Veränderung verantwortlich, und woran erkennen wir, dass sie gewirkt hat?
• Wie sieht „Erfolg" für diese Verbesserung in zwei Wochen aus?

Die besten Retro-Moderatoren wählen die Fragen nicht im Voraus für jede Phase aus. Sie hören in Phase zwei zu und lassen die Daten zeigen, welche Fragen zu Erkenntnissen und Maßnahmen für diesen konkreten Sprint am wichtigsten sind.

Wie man eine Sprint-Retrospektive durchführt

Eine gut geführte Retrospektive entsteht nicht von allein. Hier ist eine Schritt-für-Schritt-Anleitung für ein standardmäßiges einstündiges Retro für einen zweiwöchigen Sprint.

Schritt 1: Das Meeting zeitlich begrenzen

Setzen Sie ein hartes Ende und halten Sie es ein. Der Scrum Guide gibt maximal drei Stunden für einen einmonatigen Sprint vor, proportional skaliert. Für einen zweiwöchigen Sprint sind 60 bis 90 Minuten das Ziel. Teilen Sie dem Team das Zeitlimit zu Beginn mit. Es schafft Dringlichkeit und verhindert, dass Phase 4 zu kurz kommt.

Schritt 2: Stage setzen (5 Minuten)

Beginnen Sie mit einem Stimmungscheck oder einem Einwort-Check-in („Beschreiben Sie diesen Sprint in einem Wort"). Das bringt alle ins Gespräch, bevor die schwierigen Themen aufkommen, und signalisiert, dass Gefühle hier gültige Daten sind, keine Ablenkung. Erinnern Sie das Team an das Retrospektiven-Prime-Direktiv: Jeder hat sein Bestes gegeben mit den Informationen und Ressourcen, die verfügbar waren.

Schritt 3: Daten sammeln (15 Minuten)

Bitten Sie jede Person, Beobachtungen auf Haftnotizen (physisch oder digital) für die Kategorien des gewählten Formats zu notieren. Stellen Sie einen Timer. Dann teilt jede Person ihre Notizen nacheinander mit. Noch nicht diskutieren: nur sichtbar machen und gruppieren. Am Ende dieser Phase sollten Sie eine sichtbare Karte des Sprints auf dem Board haben.

Schritt 4: Erkenntnisse gewinnen (15 Minuten)

Wählen Sie die zwei oder drei Cluster mit dem meisten Potenzial aus. Fragen Sie „Warum?" statt „Was?". Wenn das Team sagt „Wir hatten zu viele Unterbrechungen", fragen Sie, was diese verursacht hat. Waren es unklare Prioritäten? Eine On-Call-Rotation, die nicht geschützt war? Stakeholder, die direkt zu den Entwicklern gegangen sind? Ursachenveränderung ändert Verhalten. Symptombehandlungen nicht.

Schritt 5: Entscheiden, was zu tun ist (15 Minuten)

Das Team stimmt über eine bis drei Verbesserungsmaßnahmen ab. Jede Maßnahme braucht eine verantwortliche Person, eine Definition of Done und einen Check-in-Termin (in der Regel das nächste Retro). Schreiben Sie sie an einen Ort, den das Team tatsächlich einsieht: das Sprint-Board, ein gemeinsames Dokument, ein wiederkehrender Tagesordnungspunkt. Wenn die Maßnahmen aus den letzten sechs Retrospektiven in einem Dokument schlummern, das niemand öffnet, ist das das Prozessproblem, das zuerst gelöst werden muss.

Schritt 6: Abschluss und Retro-Bewertung (10 Minuten)

Bitten Sie jede Person, das Retro auf einer Skala von eins bis fünf zu bewerten und ihre Bewertung in einem Satz zu begründen. Das klingt nach einer Kleinigkeit, aber so verbessert sich das Retro im Laufe der Zeit. Wenn alle eine Drei geben, weil die Diskussion oberflächlich geblieben ist, wissen Sie, dass Sie beim nächsten Mal ein anderes Format oder eine andere Moderation brauchen. Bedanken Sie sich für die Offenheit und enden Sie pünktlich.

Schritt 7: Nachverfolgung der Maßnahmen

Der Scrum Master prüft zu Beginn der Retrospektive des folgenden Sprints den Stand der Verbesserungsmaßnahmen. Nicht als Kontrolle, sondern als Signal: Haben wir tatsächlich getan, was wir gesagt haben? Wenn dieselbe Maßnahme in drei Retrospektiven nacheinander auftaucht, ist es keine Maßnahme mehr, sondern ein strukturelles Problem, das eine andere Art von Gespräch erfordert.

Häufige Anti-Muster in Retrospektiven

Auch Teams, die regelmäßig Retrospektiven durchführen, verfallen in Muster, die sie aushöhlen.

Die Beschwerderunde. Das Retro wird zum Klageforum ohne Erkenntnisse oder Maßnahmen. Lösung: Phase 3 und Phase 4 konsequent durchführen, auch wenn Phase 2 länger dauert.

Die immer gleichen fünf Wörter. „Kommunikation", „Dokumentation", „Prozess" und „Klarheit" erscheinen Sprint für Sprint auf jedem Board. Lösung: Formate wechseln, Ursachenfragen stellen und verfolgen, ob die Maßnahmen des letzten Sprints tatsächlich umgesetzt wurden.

Das schweigende Zimmer. Niemand schreibt etwas Ehrliches, weil eine Führungskraft im Raum ist oder das Team sich nicht sicher genug fühlt. Lösung: Retros nur mit dem Scrum-Team durchführen und das Prime-Direktiv zu Beginn explizit ansprechen.

Maßnahmen ohne Verantwortliche. „Das Team wird Übergaben verbessern" bedeutet, dass niemand die Übergaben verbessern wird. Lösung: Jede Maßnahme braucht eine namentlich genannte verantwortliche Person und ein messbares Ergebnis.

Retrospektiven-Erschöpfung. Das Team hat so viele unproduktive Retros erlebt, dass es innerlich abgeschaltet hat. Lösung: Das direkt ansprechen, ein wirklich anderes Format ausprobieren und mit einer echten Maßnahme abschließen, die vor dem nächsten Retro umgesetzt wird. Eine produktive Sitzung setzt Erwartungen schneller zurück als fünf Gespräche darüber, warum Retros wichtig sind.

Die Kaizen-Philosophie der kontinuierlichen Verbesserung rahmt Retrospektiven treffend: Kleine, konsequente Verbesserungen akkumulieren sich schneller als gelegentliche Überholungen. Eine bedeutsame Veränderung pro Sprint ergibt 26 Verbesserungen in einem Jahr.

Häufig gestellte Fragen

Wie lange sollte eine Sprint-Retrospektive dauern?

Der Scrum Guide setzt ein Maximum von drei Stunden für einen einmonatigen Sprint, proportional skaliert. Für zweiwöchige Sprints sind 60 bis 90 Minuten Standard. Teams mit guten Retrospektiven-Gewohnheiten kommen oft in 45 Minuten fertig, weil sie gelernt haben, schnell von Daten zu Erkenntnissen zu Maßnahmen zu gelangen.

Wer nimmt an einer Sprint-Retrospektive teil?

Die Sprint-Retrospektive ist nur für das Scrum-Team: den Scrum Master, den Product Owner und das Entwicklungsteam. Stakeholder, Führungskräfte und Kunden nehmen nicht teil. Ihre Abwesenheit ist beabsichtigt. Das Retro ist der Ort, an dem das Team über seine Zusammenarbeit spricht, und dieses Gespräch erfordert psychologische Sicherheit, die externe Beobachter zunichte machen.

Was ist der Unterschied zwischen einer Sprint-Retrospektive und einem Sprint-Review?

Das Sprint-Review konzentriert sich auf das Produkt: Das Team demonstriert, was gebaut wurde, Stakeholder geben Feedback und der Backlog wird aktualisiert. Die Sprint-Retrospektive konzentriert sich auf den Prozess: Das Team reflektiert die Zusammenarbeit und einigt sich auf Verbesserungen. Unterschiedliches Ergebnis, unterschiedliche Teilnehmer, unterschiedlicher Ton. Führen Sie diese Meetings nie zusammen durch.

Wie oft sollte man eine Retrospektive durchführen?

Jeden Sprint, ausnahmslos. Der Wert der Retrospektive steigt mit der Regelmäßigkeit: Das Team baut Vertrauen auf, Maßnahmen werden verfolgt und Verbesserung wird zur Gewohnheit statt zum Einzelereignis. Teams, die Retrospektiven in „arbeitsreichen Sprints" auslassen, sind genau die Teams, die sie am dringendsten brauchen.

Was macht ein Retrospektiven-Format gut für ein Team in Schwierigkeiten?

Beginnen Sie mit Mad-Sad-Glad oder einem einfachen Gefühls-Check-in, bevor Sie inhaltlich einsteigen. Teams in Schwierigkeiten haben oft unausgesprochene emotionale Inhalte, die eine ehrliche Datenerhebung blockieren. Sobald Gefühle benannt und anerkannt sind, kann das Team in die analytischen Phasen wechseln. Start-Stop-Continue und DAKI (Drop, Add, Keep, Improve) eignen sich gut, um aus diesen emotionalen Daten strukturierte Maßnahmen zu entwickeln.

---

Die Sprint-Retrospektive ist der Ort, an dem das agile Bekenntnis zur kontinuierlichen Verbesserung wirklich lebt oder stirbt. Jedes Team führt Sprints durch. Diejenigen, die konsequent bessere Ergebnisse liefern, sind jene, die das Retro genauso ernst nehmen wie die Sprint-Planung. Wählen Sie Ihr Format, begrenzen Sie das Meeting zeitlich, erzielen Sie eine echte Maßnahme und prüfen Sie, ob sie umgesetzt wurde, bevor das nächste Retro beginnt. Das ist die ganze Praxis.