Die Sprint Retrospektive ist eines der fünf offiziellen Ereignisse in Scrum (neben Sprint, Sprint Planning, Daily Scrum und Sprint Review). Sie findet am Ende jedes Sprints statt, nach dem Sprint Review und vor Beginn des nächsten Sprints. Ihr offizieller Zweck laut Scrum Guide ist es, den vergangenen Sprint in Bezug auf Individuen, Interaktionen, Prozesse, Werkzeuge und die Definition of Done zu überprüfen und Anpassungen für den nächsten Sprint abzuleiten.
Ablauf und Dauer
- Dauer: Maximal drei Stunden für einen einmonatigen Sprint, kürzer bei kürzeren Sprints.
- Teilnehmer: Das gesamte Scrum Team (Product Owner, Scrum Master, Developers).
- Ziel: Identifizieren von Verbesserungen, die im nächsten Sprint umgesetzt werden können.
Offizielle Scope
- Betrachtung von Menschen, Beziehungen, Prozessen, Werkzeugen und der Definition of Done.
- Erkennen von Verbesserungsmöglichkeiten zur Steigerung von Effektivität und Qualität.
- Ableitung von mindestens einer konkreten Maßnahme für den nächsten Sprint.
- Verantwortung: Das gesamte Scrum Team. Der Scrum Master unterstützt Moderation und sorgt für psychologische Sicherheit.
“Good Practices” aus der Praxis
Neben dem offiziellen Rahmen hat sich in der Praxis eine Vielzahl an Methoden etabliert, um Retrospektiven lebendig und wirksam zu gestalten:
- Start–Stop–Continue: Das Team diskutiert, was begonnen, gestoppt oder fortgesetzt werden sollte.
Beispiel: „Start: Pair Programming regelmäßig nutzen. Stop: Reviews ohne Vorbereitung. Continue: Gemeinsame Daily-Moderation.“
- Mad–Sad–Glad: Jedes Teammitglied teilt, was es im Sprint wütend, traurig oder glücklich gemacht hat.
Beispiel: „Mad: Build brach ständig. Sad: Wenig Feedback vom PO. Glad: Daily war diesmal sehr effektiv.“
- Timeline-Retrospektive: Gemeinsames Visualisieren der Sprint-Ereignisse in chronologischer Reihenfolge. Hilft, Muster und Wendepunkte zu erkennen.
- 5 Whys (Root Cause Analysis): Probleme werden durch mehrmaliges Nachfragen der Ursachen auf den Grund analysiert.
- Appreciation Round: Am Ende bedankt sich jedes Teammitglied bei einem anderen für eine konkrete Unterstützung.
- Experiment Board: Statt allgemeiner Verbesserungen werden konkrete Experimente mit Hypothese und Messkriterium formuliert.
Beispiel: „Hypothese: Wenn wir ein Kanban-Board für Bugs einführen, sinkt die Zahl offener Tickets um 30 %.“
Diese Formate sind nicht Teil des Scrum Guides, haben sich aber als Best Practices in vielen Organisationen bewährt.
Typische Missverständnisse
- „Retrospektiven sind optional“ – falsch: Sie sind ein verpflichtendes Scrum-Event.
- „Retrospektiven sind nur Feedback-Runden“ – ihr Ziel ist es, konkrete Verbesserungen und Experimente zu beschließen.
- „Nur der Scrum Master profitiert“ – in Wahrheit profitieren alle Beteiligten, da Zusammenarbeit, Transparenz und Leistung verbessert werden.
Praktische Relevanz in Transformationen
Die Retrospektive ist ein zentrales Werkzeug der lernenden Organisation. Sie stärkt Eigenverantwortung, macht Dysfunktionen sichtbar und ermöglicht kontinuierliche Verbesserung. In agilen Transformationen fungiert sie als Multiplikator: kleine, regelmäßige Verbesserungen summieren sich zu nachhaltiger Veränderung.
CALADE Perspektive
In vielen Organisationen erleben wir, dass Retrospektiven routiniert und oberflächlich durchgeführt werden. CALADE unterstützt Teams und Scrum Master dabei, Retrospektiven zu einem echten Motor für Kulturwandel und systemische Verbesserung zu machen – durch Methodenvielfalt, Coaching und praxisnahe Ausbildung. So werden Retrospektiven vom Ritual zum strategischen Hebel kontinuierlicher Weiterentwicklung.
Verwandte Begriffe
- Sprint
- Sprint Review
- Scrum Master
- Kontinuierliche Verbesserung (Kaizen)
- Psychologische Sicherheit
← zurück zur Übersicht