Wie man eine Sprint-Retrospektive durchführt, die zu konkretem Handeln führt

Eine Sprint-Retrospektive ist nur dann sinnvoll, wenn sie das nächste Sprint-Ergebnis verändert. Ein Board voller ehrlicher Beobachtungen ist nur die Mitte des Prozesses; das Meeting sollte mit wenigen Verbesserungen enden, die Verantwortliche haben und überprüfbar sind.

Dieser Leitfaden bietet dem Facilitator einen wiederholbaren 60-Minuten-Ablauf für ein Team, das einen zweiwöchigen Sprint abgeschlossen hat. Passen Sie die Zeitfenster je nach Team und Sprint-Komplexität an. Der offizielle Scrum Guide erlaubt bis zu drei Stunden für einen einmonatigen Sprint und weist darauf hin, dass kürzere Sprints meist ein kürzeres Meeting benötigen.

In diesem Leitfaden

• Die Kurzfassung
• Vor dem Meeting vorbereiten
• Praktische 60-Minuten-Agenda verwenden
• Beobachtungen unabhängig sammeln
• Themen gruppieren und abstimmen
• Diskussion in Handlung verwandeln
• Ein Beispiel überprüfen
• Häufige Fehler in Retrospektiven vermeiden
• Facilitator-Checkliste verwenden

Die Kurzfassung

Führen Sie die Retrospektive in sieben Schritten durch:

1. Zweck wiederholen und einen sicheren, schuldfreien Rahmen schaffen.
2. Die vorherige Verbesserung und relevante Sprint-Belege überprüfen.
3. Allen erlauben, Beobachtungen hinzuzufügen, bevor die offene Diskussion beginnt.
4. Verwandte Karten zu Themen gruppieren.
5. Abstimmen, um die wenigen Themen zu wählen, die Zeit wert sind.
6. Ursachen und Optionen erkunden, nicht Schuldige suchen.
7. Eine oder zwei konkrete Maßnahmen mit Verantwortung und Prüfungspunkt festlegen.

Die Sprint-Retrospektive ist kein Statusbericht oder Leistungsfeedback. Im Scrum dient sie dazu, Wege zur Steigerung von Qualität und Effektivität zu planen, indem der Sprint in Bezug auf Menschen, Interaktionen, Prozesse, Werkzeuge und die Definition of Done inspiziert wird.

Vor der Retrospektive: Belege und Sicherheit vorbereiten

Ein hilfreiches Gespräch beginnt bereits vor dem Meeting. Bereiten Sie genügend Belege vor, um das Gedächtnis zu unterstützen, ohne das Meeting in eine Metriken-Präsentation zu verwandeln.

Bringen Sie eine kleine Auswahl an Signalen mit, zum Beispiel:

• das Sprint-Ziel und ob es erreicht wurde;
• übertragene Arbeit und die Gründe für die Verschiebung;
• Vorfälle, Release-Probleme oder wiederholte Unterbrechungen;
• Zykluszeit- oder Flussänderungen, die das Team bereits überwacht;
• Qualitätssignale, einschließlich entkommener Fehler oder Nacharbeit;
• die vorherige Retrospektiven-Maßnahme und ihr aktuelles Ergebnis.

Belege sollen Fragen anstoßen, nicht abschließen. „Drei Posten sind übergegangen“ ist ein Signal. „Entwickler haben schlecht geschätzt“ ist bereits ein Urteil.

Wählen Sie Impulse, die zum Sprint passen

Ein einfaches Drei-Spalten-Board funktioniert gut für ein Team, das ein direktes Gespräch benötigt:

• Was hat uns geholfen?
• Was hat uns behindert?
• Was sollten wir als Nächstes ändern?

Ändern Sie die Impulse, wenn sich die Situation ändert. Eine Release-Retrospektive kann sich auf Vorbereitung, Durchführung und Nachbereitung konzentrieren. Ein neues Team braucht möglicherweise Impulse zu Klarheit und Zusammenarbeit. Wechseln Sie Formate nicht nur zur Abwechslung; wählen Sie die Struktur, die dem Team hilft, die tatsächlich geleistete Arbeit zu reflektieren.

Wählen Sie ein fertiges Board aus der Retrospektiven-Vorlagenbibliothek, wenn dessen Impulse zum Gespräch passen:

Sehen Sie sich die Spalten und Meeting-Einstellungen auf der Vorlagenseite an, bevor Sie den Retrospektiven-Ersteller öffnen. Nach dem Sammeln des Feedbacks wählen Sie ein oder zwei Verbesserungen über das gesamte Board; die Anzahl der Spalten ist keine Vorgabe für Aktionspunkte.

Entscheiden Sie, wie die Teilnahme abläuft

Laden Sie das gesamte Scrum Team ein. Entscheiden Sie, wer moderiert, wie lange die stille Schreibphase dauert, wie Stimmen verteilt werden und ob anonyme Beiträge sinnvoll sind. Agilo unterstützt konfigurierbare Spalten, Kommentare, Reaktionen, Abstimmung und optionale Anonymität.

Anonymität kann die Hemmschwelle senken, ein sensibles Thema anzusprechen, schafft aber nicht von selbst psychologische Sicherheit. Der Facilitator muss weiterhin Schuldzuweisungen stoppen, Personen vor Vergeltung schützen und die Diskussion auf Systeme und Entscheidungen lenken, die das Team beeinflussen kann.

Eine praxisorientierte 60-Minuten-Agenda

Ist das Team neu in Retrospektiven, halten Sie die Struktur einfach und erklären Sie jede Phase. Erfahrene Teams können kürzere Anleitungen verwenden, profitieren aber dennoch von sichtbaren Zeitfenstern und einem klaren Ergebnis.

Schritt 1: Mit Zweck öffnen, nicht mit Formalität

Beginnen Sie, indem Sie das Ziel benennen:

Wir sind hier, um zu verstehen, wie dieser Sprint lief und ein oder zwei Änderungen auszuwählen, die den nächsten Sprint effektiver machen.

Stimmen Sie dann einfachen Regeln zu: Unvollständige Informationen annehmen, nur über beobachtete Ereignisse sprechen, andere ausreden lassen und den Prozess kritisieren ohne Personen zu attackieren.

Überprüfen Sie die letzte Retrospektiven-Maßnahme, bevor Sie neue erstellen. Wenn sie abgeschlossen ist, fragen Sie, was sich geändert hat. Wenn nicht, erkunden Sie die Gründe. Das Überspringen dieser Phase signalisiert dem Team, dass Verpflichtungen nach dem Meeting verschwinden.

Schritt 2: Beobachtungen sammeln, bevor die Diskussion beginnt

Geben Sie allen fünf bis acht stille Minuten, um Karten hinzuzufügen. Das stille Schreiben verringert den Vorteil der schnellsten Sprecher und ermöglicht den Teilnehmern eine eigene Sicht, bevor die erste Meinung den Raum prägt.

Bitten Sie um konkrete Beobachtungen:

• Was hat uns geholfen, das Sprint-Ziel zu erreichen?
• Wo hat Arbeit gewartet, ist zurückgeworfen worden oder erforderte Nacharbeit?
• Welche Annahme hat uns überrascht?
• Was sollten wir schützen, weil es funktionierte?
• Was liegt in unserem Einfluss, um es im nächsten Sprint zu ändern?

Eine Karte sollte jeweils ein Signal enthalten. „Release-Bereitschaft“ ist zu grob. „QA erhielt den stabilen Build erst 20 Minuten vor dem Release-Fenster“ gibt dem Team eine untersuchbare Aussage.

Aktuelle Agilo-Oberfläche mit fiktiven Teilnehmern: Beobachtungen sind neben den aus der Diskussion erstellten Aktionspunkten sichtbar.

Schritt 3: Signale gruppieren und über Wichtiges abstimmen

Lesen Sie die Karten zur Klärung, nicht für eine sofortige Debatte. Bitten Sie den Verfasser, eine unklare Formulierung zu erklären, und gruppieren Sie dann Karten, die dasselbe System oder wiederholte Effekte beschreiben.

Zum Beispiel könnten diese Karten zusammengehören:

• „Der Build kam nach dem geplanten Testfenster an.“
• „Regression wurde auf die letzte Stunde zusammengepresst.“
• „Zwei Fixes wurden nach Code-Freeze zusammengeführt.“

Das gemeinsame Thema könnte „Freigabeänderungen lassen kein stabiles Regressionsfenster“ sein. Durch Gruppierung wird verhindert, dass das Team dasselbe Problem dreimal unter verschiedenen Bezeichnungen diskutiert.

Als Nächstes wird abgestimmt. Das Voting dient der Priorisierung, nicht der wissenschaftlichen Messung des Problems. Wählen Sie zwei oder drei Hauptthemen aus und prüfen Sie dann, ob ein niedriger bewerteter Punkt ein dringendes Sicherheits-, Ethik- oder Betriebsrisiko darstellt, das nicht ignoriert werden sollte.

Schritt 4: Ursachen erforschen, ohne die Sitzung zum Tribunal werden zu lassen

Diskutieren Sie jeweils ein Thema. Trennen Sie das Ereignis, dessen Auswirkungen, beitragende Bedingungen und mögliche Änderungen.

Nützliche Fragen sind unter anderem:

• Was ist passiert und wann haben wir es erstmals bemerkt?
• Unter welchen Bedingungen war dieses Ergebnis wahrscheinlich?
• Wo warteten Informationen oder wurden weitergegeben?
• Welche Annahme oder Richtlinie beeinflusste die Entscheidung?
• Welchen Teil kann dieses Team im nächsten Sprint beeinflussen?
• Was wäre das kleinste Experiment, das uns Beweise liefert?

Vermeiden Sie die Frage „Wer hat versagt...?“, wenn die nützlichere Frage „Was machte es leicht, den Fehler zu wiederholen?“ lautet. Individuelle Verantwortlichkeit bleibt wichtig, aber Schuldzuweisungen verengen meist die Beweisgrundlage, bevor das System vollständig verstanden wird.

Begrenzen Sie die Diskussion. Wenn ein Thema einen technischen Workshop oder eine Managemententscheidung erfordert, beauftragen Sie diese Nachverfolgung, anstatt die gesamte Retrospektive dafür zu verwenden.

Schritt 5: Erstellen Sie ein oder zwei umsetzbare Verbesserungen

Ein guter Aktionspunkt beschreibt ein beobachtbares Verhalten oder eine Veränderung im Team. Er umfasst:

• eine klare Handlung, keine bloße Absicht;
• eine verantwortliche Person, die es vorantreibt;
• einen Zeitpunkt oder Anlass zur Überprüfung;
• ein Ergebnis, das zeigt, ob die Änderung geholfen hat;
• einen Link zur Auslöserbeobachtung, wenn sinnvoll.

Vergleichen Sie diese Beispiele:

Wenn jede Maßnahme mit „Kommunikation verbessern“ beginnt, hat die Retrospektive einen Horoskoptext statt eines Plans geliefert. Machen Sie das nächste beobachtbare Verhalten sichtbar. 🙂

Eine Maßnahme bleibt mit der sie auslösenden Beobachtung verbunden und erfasst Priorität, Status sowie Verantwortlichkeit.

Zwei verantwortete Maßnahmen sind meist wertvoller als zwölf Absichten. Scrum.org empfiehlt ebenso, Verbesserungen zu priorisieren und bei zu vielen die ein oder zwei wichtigsten für den nächsten Sprint auszuwählen.

Für weitere Situationen nutzen Sie die Beispiele für Retrospektiven-Aktionspunkte: Sie behandeln Review-Queues, Abhängigkeiten und Wissensaustausch mit kopierbaren Vorlagen und Prüfpunkten für Abschluss und Wirkung.

Schritt 6: Schließen Sie den Rückkopplungszyklus

Bevor das Treffen endet, lesen Sie jede Maßnahme laut vor und bestätigen Sie:

• der Verantwortliche stimmt zu;
• das Team versteht die erwartete Veränderung;
• die Maßnahme liegt im Einflussbereich des Teams oder hat einen klaren Eskalationspfad;
• der Überprüfungspunkt ist sichtbar.

Fügen Sie eine wirkungsvolle Verbesserung dem nächsten Sprint-Backlog hinzu, wenn das der beste Weg ist, die Arbeit sichtbar zu machen. Beginnen Sie die nächste Retrospektive mit der Überprüfung des Ergebnisses. Abgeschlossene, geänderte und verworfene Experimente können dem Team alle etwas lehren – solange das Ergebnis betrachtet wird.

Schließen Sie mit einer kurzen Kontrolle ab: „Hat uns dieses Meeting geholfen, eine nützliche Veränderung zu wählen?“ Nutzen Sie die Antwort, um die nächste Retrospektive selbst zu verbessern.

Ein Praxisbeispiel: Vom Sprint-Signal zur verantworteten Maßnahme

Stellen Sie sich ein Team vor, das am Freitagabend eine Freigabe durchgeführt hat.

Signale auf dem Board

• QA erhielt das stabile Build 20 Minuten vor dem Release-Fenster.
• Zwei „kleine“ Umfangsänderungen kamen nach dem geplanten Freeze an.
• Entwickler blieben länger, um ein Konfigurationsproblem zu beheben.
• Die Freigabe erfolgte, aber die Regressionsabdeckung war reduziert.

Gruppiertes Thema

Das Team gruppiert die Karten unter „späte Umfangsänderungen haben das Regressionsfenster entfernt.“ Dieses Thema erhält die meisten Stimmen, da es Qualität, Überstunden und Vorhersehbarkeit beeinträchtigte.

Diskussion

Die Gruppe stellt fest, dass der Code-Freeze als Empfehlung betrachtet wurde. Verkaufsanfragen kamen per Chat, niemand hatte die Befugnis, sie abzulehnen, und QA hatte keinen sichtbaren Bereitschafts-Checkpoint.

Gewähltes Experiment

Für die nächsten zwei Releases wird der Umfang 48 Stunden vor dem Release-Fenster eingefroren. Jede Ausnahme erfordert eine sichtbare Entscheidung vom Product Owner und Tech Lead. Der Tech Lead übernimmt die Überprüfung; das Team bewertet späte Ausnahmen und Regressionszeit in der nächsten Retrospektive.

Diese Maßnahme verspricht kein „besseres Teamwork“. Sie ändert eine Entscheidungsregel, benennt einen Verantwortlichen, begrenzt das Experiment und definiert, was das Team überprüfen wird.

Häufige Fehler, die Retrospektiven sinnlos erscheinen lassen

Beschwerden sammeln ohne Änderung auszuwählen

Probleme zu benennen kann erleichternd sein, aber wiederholte Beobachtungen ohne Anpassung erzeugen Zynismus. Reservieren Sie Zeit für die Maßnahmenphase, bevor die Diskussion ausufert.

Zu viele Maßnahmen erstellen

Eine lange Liste verteilt die Verantwortung und konkurriert mit der Sprint-Arbeit. Wählen Sie ein bis zwei wertvolle Änderungen und behalten Sie andere Ideen für später sichtbar.

Vorherige Maßnahmen ignorieren

Das Team kann nicht lernen, ob ein Experiment funktioniert hat, wenn niemand es überprüft. Beginnen Sie jede Retrospektive mit der letzten Verpflichtung.

Abstimmung lässt ernste Risiken untergehen

Stimmen zeigen gemeinsames Interesse, nicht die Schwere. Ein Sicherheits-, Gesundheits-, Belästigungs- oder Compliance-Problem benötigt eine angemessene Reaktion, selbst wenn es nur eine Stimme erhält.

Die Retrospektive zur Leistungsbewertung machen

Menschen hören auf, nützliche Informationen zu teilen, wenn Beobachtungen zur Bewertung oder Bestrafung genutzt werden. Untersuchen Sie das Arbeitssystem und die Team-Interaktionen; individuelle Leistung wird über den passenden privaten Prozess geregelt.

Nur das besprechen, was das Team nicht kontrollieren kann

Externe Blocker sind wichtig, aber das Meeting benötigt dennoch einen nächsten Schritt: einen Eskalationsverantwortlichen, eine Anforderung von Nachweisen, eine Grenze oder eine kleine Änderung im Einflussbereich des Teams.

Checkliste für Moderatoren

Vor dem Meeting:

• Wählen Sie Fragen, die zum Sprint passen;
• Bereiten Sie einige neutrale Beweispunkte vor;
• Überprüfen Sie den Status vorheriger Maßnahmen;
• Konfigurieren Sie Board, Abstimmung, Anonymität und Zeitrahmen;
• Klären Sie, wer moderiert und wer teilnimmt.

Während des Meetings:

• Geben Sie Zweck und Arbeitsregeln an;
• Geben Sie jedem Ruhezeit zum Schreiben;
• Klären Sie, bevor Sie debattieren;
• Gruppieren Sie verwandte Signale;
• Stimmen Sie ab, prüfen Sie dann dringende Risiken mit niedrigen Stimmen;
• Diskutieren Sie Ursachen und Einfluss statt Schuldzuweisung;
• Reservieren Sie die letzten zehn Minuten für Maßnahmen.

Vor dem Abschluss:

• Behalten Sie ein bis zwei Verbesserungen;
• Weisen Sie jeder Maßnahme einen Verantwortlichen zu;
• Definieren Sie das nächst beobachtbare Verhalten;
• Vereinbaren Sie einen Zeitpunkt zur Überprüfung des Ergebnisses;
• Fragen Sie, ob die Retrospektive selbst nützlich war.

Führen Sie den Workflow in Agilo aus

Agilo Retrospectives verwaltet Beobachtungen, Gruppierungen, Abstimmungen, Kommentare, Reaktionen und zugewiesene Maßnahmen auf einem gemeinsamen Board. Sie können die Fragen und Teilnahme-Einstellungen konfigurieren, eine Maßnahme mit ihrer Quellkarte verbinden und den Status nach dem Meeting sichtbar halten.

Erstellen Sie ein Retrospektiven-Board, wenn Team, Fragen und Zeitrahmen bereit sind.

Quellen und weiterführende Literatur

• Der offizielle Scrum Guide — Zweck, Inspektionsbereiche, Verbesserungsergebnis und maximale Zeitbox für die Sprint-Retrospektive.
• Scrum.org: Durchführung der Sprint-Retrospektive — ein einfaches Board, Diskussion, Priorisierung und Auswahl von Verbesserungen.
• Scrum.org: Ihre Sprint-Retrospektiven effektiver gestalten — häufige Anti-Patterns und Anleitung zur Priorisierung von ein oder zwei Verbesserungen.