Sprint-Retrospektive: So führst du eine durch, die euer Team wirklich weiterbringt

Die Sprint-Retrospektive ist die am meisten missbrauchte Zeremonie in Scrum. Teams führen sie durch, weil das Framework es verlangt. Sie folgen im jeden Sprint demselben Format, weil es vertraut ist. Sie generieren dieselben Maßnahmen, weil die zugrunde liegenden Probleme nie gelöst werden. Dann fragen sie sich, warum die Zeremonie sinnlos erscheint.

Es muss nicht so sein. Die Retrospektive ist die eine Zeremonie in Scrum, die speziell dafür konzipiert ist, alles andere zu verbessern. Gut durchgeführt, ist es das Meeting mit dem größten Hebel, das dein Team hat. Schlecht durchgeführt, sind es 90 Minuten verwalteter Frustration.

Dieser Leitfaden handelt davon, es gut zu machen.

Was eine Sprint-Retrospektive ist (und was sie nicht ist)

Der Scrum Guide definiert die Sprint-Retrospektive als ein Meeting, um "Wege zu planen, die Qualität und Effektivität zu steigern." Drei Dinge stechen in dieser Definition hervor.

Planen — nicht diskutieren, nicht erkunden, nicht reflektieren. Planen. Das Ergebnis sind Entscheidungen über zukünftiges Verhalten, nicht die Dokumentation vergangenen Verhaltens.

Steigern — die Basislinie wird immer höher gelegt. Wenn du in einem Jahr 25 Retrospektiven durchführst, ohne messbare Verbesserungen, hast du keine Retrospektiven durchgeführt. Du hattest wöchentliche Überprüfungssitzungen mit einem netteren Namen.

Qualität und Effektivität — beide Dimensionen sind wichtig. Qualität des Produkts. Effektivität der Teamarbeit. Ingenieurpraktiken, Kollaborationsmuster, Kommunikationsstrukturen, Meeting-Overhead. Alles ist fair game.

Was die Retrospektive nicht ist: ein Statusupdate, ein Ort, um Beschwerden ohne Lösung zu äußern, eine Team-Building-Übung, eine Demo oder eine Sprint-Überprüfung. Diese Dinge haben ihren Platz. Das hier ist es nicht.

Wer an einer Sprint-Retrospektive teilnimmt

Die Sprint-Retrospektive ist für das Scrum-Team: die Entwickler:innen, die Scrum Master:in und den Product Owner. Alle drei. Die Anwesenheit des Product Owners wird oft diskutiert — einige Teams finden, dass seine Anwesenheit die Offenheit hemmt. Aber der Scrum Guide ist klar: Der PO ist Teil des Scrum-Teams und nimmt teil.

Wenn die Offenheit durch die Anwesenheit des POs tatsächlich gehemmt wird, ist das das Problem, das gelöst werden muss — nicht die Teilnahmepolitik. Eine Retrospektive, in der Teammitglieder nicht sagen können, was wahr ist, wenn ihr Product Owner anwesend ist, ist ein Team mit einem Vertrauensproblem, das das Format der Retrospektive nicht beheben kann.

Stakeholder, Manager:innen und externe Parteien nehmen nicht teil. Die Retrospektive ist für die Personen, die die Arbeit machen.

Zeitrahmen

Maximal 3 Stunden für einen einmonatigen Sprint. 90 Minuten für einen zweiwöchigen Sprint. 45–60 Minuten für erfahrene Teams mit hohem Vertrauen und wenigen systemischen Problemen.

Strikte Zeitrahmen sind Merkmale, keine Fehler. Sie zwingen zur Priorisierung. Wenn alles diskutierbar ist, wird nichts entschieden.

Eine getestete Sprint-Retrospektive Agenda (90 Minuten)

Hier ist eine Struktur, die funktioniert. Passe sie an — aber überspringe keine Phasen.

Eröffnung: Die Bühne bereiten (10 min)

Lest die Retrospektive Prime Directive gemeinsam laut vor. Es ist kein Ritual — es ist ein Reframing. Es verschiebt den Raum von Schuldzuweisungen zu Erkundungen.

Dann: eine Runde Check-in. Bitte jede Person, ein Wort zu teilen, das beschreibt, wie sie sich auf die Retrospektive vorbereitet fühlt. Keine Erklärungen, keine Diskussion. Nur die Daten. Wenn die Hälfte der Wörter "erschöpft" oder "frustriert" sind, weißt du, was für eine Session das sein muss.

Phase 1: Daten sammeln (15 min)

Gib allen Haftnotizen. In Stille schreibt jede Person:

• Was ist in diesem Sprint passiert, worüber du sprechen möchtest?
• Was hast du beobachtet — gut, schlecht oder überraschend?

Hänge die Notizen an die Tafel. Die Scrum Master:in (oder Moderator:in) gruppiert sie still in Cluster, während alle lesen.

Diese stille Phase ist nicht optional. Gruppen, die direkt zum verbalen Datensammeln übergehen, verankern sich an dem, der zuerst spricht. Du möchtest das vollständige Bild des Raumes, nicht das Bild der lautesten Stimme.

Phase 2: Erkenntnisse generieren (20 min)

Wähle die zwei oder drei Cluster mit den meisten Notizen oder den höchsten Punktzahlen (schnelles Hand- oder Punkt-Feedback). Für jedes Cluster:

• Lies die Notizen im Cluster laut vor.
• Frage: "Was ist das Muster hier? Was verursacht das?"
• Wende die 5 Whys an, wenn die Ursache nicht klar ist.

Setze die Regel durch: noch nicht zu Lösungen springen. Die Erkenntnisphase dient dem Verständnis, nicht dem Beheben. Teams, die die Einsicht überspringen und direkt zu Lösungen übergehen, beheben die falschen Dinge.

Häufige Erkenntnisse, die es wert sind, vertieft zu werden:

• Prozesslücken (Übergaben, die fallen gelassen werden, unklare Definitionen)
• Kommunikationsfehler (wer musste was wann wissen und wusste es nicht)
• Technische Schulden, die die Lieferung bremsen
• Externe Abhängigkeiten, die nicht kartiert wurden
• Schätzmuster (werden bestimmte Arten von Arbeit konstant unterbewertet?)

Phase 3: Entscheiden, was zu tun ist (20 min)

Jetzt Lösungen. Aber nur für die 2–3 wichtigsten Erkenntnisse.

Für jede Erkenntnis frage: "Was ist die eine spezifische Änderung, die wir vornehmen könnten, um das anzugehen?" Schreibe die Antwort als Maßnahme mit drei Feldern:

• Was: spezifisch, konkret, eindeutig
• Wer: ein:e Verantwortliche:r (nicht "das Team")
• Bis wann: ein Datum, nicht "nächster Sprint"

Füge die Maßnahmen sofort dem Sprint-Backlog hinzu. Nicht eine separate Confluence-Seite. Nicht ein Notion-Dokument. Das Sprint-Backlog — wo das Team sie tatsächlich sehen wird.

Phase 4: Abschluss (5 min)

Eine Runde: jede Person teilt ein Wort oder einen Satz über die Session. Was war nützlich? Was würdest du ändern? Danke dem Team. Beende pünktlich.

Die häufigsten Fehler bei Sprint-Retrospektiven

Die gleichen Probleme tauchen in jedem Sprint auf

Dies ist das demoralisierteste Muster. Das Team hebt "unklare Anforderungen" oder "zu viele Unterbrechungen" Sprint für Sprint hervor. Nichts ändert sich.

Die Ursache ist fast immer eines von drei Dingen: Maßnahmen werden nicht verfolgt (sie wurden vereinbart, aber nie überprüft), Maßnahmen sind zu vage (niemand weiß, was "Kommunikation verbessern" operationell bedeutet), oder die Wurzelursache liegt außerhalb der Kontrolle des Teams (in diesem Fall sollte die Retro-Maßnahme sein: an jemanden eskalieren, der es beheben kann).

Lösung: Beginne jede Retrospektive mit der Überprüfung der Maßnahmen des letzten Sprints. Explizit. Bevor neue Daten generiert werden. Wenn Maßnahmen nicht abgeschlossen wurden — das ist das erste Thema.

Geringe Teilnahme

Die Hälfte des Raums bleibt still. Die gleichen zwei oder drei Personen generieren 80% des Inhalts. Die Maßnahmen spiegeln ihre Prioritäten wider.

Lösung: Beginne immer mit dem Datensammeln schriftlich, nicht verbal. Stille individuelle Haftnotizen schaffen einen Raum voller Mitwirkender:innen statt eines Publikums. Verwende 1-2-4-All für Diskussionsrunden — Paargespräche vor der Plenarsitzung erhöhen konsequent die Teilnahme.

Die Retrospektive fühlt sich wie eine Beschwerdesitzung an

Hohe Energie beim Generieren von Problemen, niedrige Energie beim Generieren von Lösungen. Maßnahmen sind vage oder nicht zugeordnet. Die Scrum Master:in beendet die Session mit dem Gefühl, Therapeut:in zu sein.

Lösung: Setze die Einsichtphase durch. Gehe von der Beobachtung zur systemischen Ursache, bevor du Lösungen ansprichst. Und begrenze die Problemerzeugung auf 25% der Session-Zeit. Der Großteil der Zeit sollte für Einsicht und Maßnahmen aufgewendet werden.

Das Team sagt, alles sei in Ordnung

In neuen Teams oder Teams mit hierarchischer Kultur sind die Daten verdächtig positiv. Was lief gut? Alles. Was könnte sich verbessern? Nicht viel.

Lösung: Verwende anonyme Eingaben. Vor-Retrospektive-Umfragen (anonymes Google-Formular) bringen ans Licht, was die Leute im Raum nicht sagen werden. Baue psychologische Sicherheit explizit und über Zeit auf — du kannst sie nicht in einer Session herstellen.

Rotierende Formate: Warum es ein Fehler ist, jedes Mal dasselbe Format zu verwenden

Start/Stop/Continue ist für zwei oder drei Sprints in Ordnung. Danach wird es Hintergrundgeräusch. Das Team weiß, was kommt, das Format hört auf, Überraschungen zu fördern, und die Teilnahme sinkt.

Rotieren Sie Formate bewusst:

• Sprint 1–2: Start/Stop/Continue (einfach, klar)
• Sprint 3: Sailboat Retrospective (visuell, bringt systemische Kräfte ans Licht)
• Sprint 4: Mad Sad Glad (wenn die Teamenergie Aufmerksamkeit benötigt)
• Sprint 5: DAKI Retrospective (aktionsorientiert)
• Sprint 6: Starfish Retrospective (nuanciert, fünf Dimensionen)

Gib das Format zu Beginn der Retrospektive bekannt — oder besser, lass das Team wählen. Die Verantwortung für das Format erhöht das Engagement damit.

Was gute Retrospektiven-Moderator:innen von großartigen trennt

Gute Moderator:innen folgen der Struktur. Großartige Moderator:innen lesen den Raum und passen sich an.

Die wichtigsten Moderationsfähigkeiten in einer Retrospektive sind:

Stille tolerieren. Warte nach einer Frage. Warte wirklich. Die meisten Moderator:innen sind mit Stille unwohl und füllen sie mit mehr Worten. Eine fünfsekündige Stille nach "Was verursacht dieses Muster?" wird bessere Antworten liefern als eine gut formulierte Nachfolgefrage.

Beobachtung vs. Interpretation. "Ich bemerke, dass dieses Cluster acht Notizen über die Bereitstellung hat" ist eine Beobachtung. "Ich denke, wir haben ein Bereitstellungsproblem" ist eine Interpretation. Halte Beobachtungen von Interpretationen getrennt. Nenne, was du siehst, bevor du fragst, was es bedeutet.

Die Einsichtphase schützen. Teams wollen sofort von "Wir haben ein Problem identifiziert" zu "Hier ist die Lösung" springen. Verlangsamen Sie sie. Eine Lösung für ein schlecht verstandenes Problem ist normalerweise ein Pflaster auf einem systemischen Versagen.

Die Energie verfolgen. Wenn die Energie erheblich sinkt, nenne es: "Ich bemerke, dass die Energie im Raum gesunken ist. Was passiert?" Das ist keine sanfte Moderation — es ist Datensammlung darüber, was im System passiert, das du zu verstehen versuchst.

Die Retrospektive ist nur so gut wie das, was danach passiert

Die Retrospektive endet, wenn das Team den Raum verlässt. Was als Nächstes passiert, bestimmt, ob es nützlich war.

Überprüfe die Maßnahmen beim nächsten Sprint-Planning. Besser: Baue eine 10-minütige Überprüfung der Retrospektivmaßnahmen in jedes Daily Stand-up ein. Noch besser: Mach ein Teammitglied zum "Verbesserungsbeauftragten", der die Retro-Maßnahmen verfolgt und explizit darüber berichtet.

Die Retrospektive ist ein Feedbackloop. Wie alle Feedbackloops funktioniert sie nur, wenn das Signal das System tatsächlich verändert. Wenn Retro-Maßnahmen in einer Confluence-Seite verschwinden, die niemand liest, ist der Loop unterbrochen. Behebe zuerst den Loop.