Die meisten Teams führen die gleiche Retrospektive durch, unabhängig davon, woran sie tatsächlich arbeiten. Zwei Wochen nach Beginn der Entdeckungsforschung fragen sie: „Was ist gut gelaufen, was nicht.“ Drei Tage nach dem Start, dasselbe Format. Tief im Iterationsmodus zur Optimierung der Konvertierung, wieder dieselben Fragen.
Das ist eine verpasste Chance. Die Arbeit, die Sie bei der Entdeckung leisten, unterscheidet sich grundlegend von der Arbeit, die Sie während einer Markteinführung leisten. Die Risiken sind unterschiedlich, die Fehlerarten sind unterschiedlich und die Fragen, die es wert ist, gestellt zu werden, sind unterschiedlich. Das sollten Ihre Retrospektiven widerspiegeln.
So passen Sie Ihr Retrospektivformat an jede Phase der Produktentwicklung an, damit Sie tatsächlich die wichtigen Erkenntnisse ans Licht bringen.
Warum ein Format nicht für alle passt
Die Aufgabe einer Retrospektive besteht darin, Ihnen dabei zu helfen, Ihre aktuelle Arbeit zu verbessern. Beim Entdecken lernt „die Arbeit“ schnell. Beim Bau kommt es auf die Ausführungsqualität an. Beim Start erfolgt die funktionsübergreifende Koordination. Während der Iteration werden kluge Wetten darüber getroffen, was beibehalten, gekürzt oder erweitert werden soll.
Wenn Sie ein generisches Retrospektivformat verwenden, erhalten Sie in der Regel generische Beobachtungen. Teams diskutieren standardmäßig Prozessbeschwerden (Standups sind zu lang, Jira ist chaotisch), anstatt die tiefergehenden Fragen zu untersuchen, die für ihre aktuelle Phase spezifisch sind. Durch die Anpassung Ihres Formats lenken Sie das Gespräch auf das, was tatsächlich Aufmerksamkeit erfordert.
Stufe 1: Entdeckung – Optimierung für Lerngeschwindigkeit
Während der Entdeckung führt Ihr Team Experimente durch, spricht mit Kunden und testet Annahmen. Das größte Risiko besteht nicht darin, dass man etwas langsam aufbaut; Es liegt daran, dass Sie völlig das Falsche bauen.
Retrospektives Format: Hypothese / Test / Lernen / Nächste Aktion
Diese vierspaltige Struktur zwingt das Team dazu, zu artikulieren, was es angenommen hat, wie es es getestet hat, was es tatsächlich gelernt hat und was es als nächstes tun wird. Es sorgt dafür, dass das Gespräch eher auf Beweisen als auf Meinungen basiert.
Zu stellende Fragen:
- Welche Annahmen haben wir in diesem Zyklus bestätigt oder entkräftet?
- Wo haben wir Zeit mit Recherchen verbracht, die kein klares Signal hervorbrachten?
- Sprechen wir mit den richtigen Leuten oder stecken wir in einem komfortablen Segment fest?
- Wie schnell bewegen wir uns von der Frage zur Antwort?
Worauf Sie achten sollten:
Wenn Ihr Team nicht klar darlegen kann, was es in den letzten ein bis zwei Wochen gelernt hat, stimmt etwas nicht. Entweder ist die Forschung unkonzentriert, die Experimente sind zu langsam oder Erkenntnisse gehen zwischen den Teammitgliedern verloren. Die Retrospektive soll zeigen, welches davon der Engpass ist.
Ein weiteres häufiges Muster: Teams, die ständig „validieren“, ohne jemals eine Idee zunichte zu machen. Wenn jede Hypothese bestätigt wird, stellen Sie wahrscheinlich Leitfragen oder interpretieren mehrdeutige Daten zu großzügig. Ein gesunder Entdeckungsprozess macht Annahmen regelmäßig ungültig.
Stufe 2: Erstellen – Geschwindigkeit und Qualität ausbalancieren
Sobald Sie überzeugt sind, was gebaut werden soll, beginnt die Arbeit mit der Ausführung. Die Risiken bestehen nun in einer Ausweitung des Umfangs, unklaren Anforderungen, Integrationsproblemen und der langsamen Anhäufung von Verknüpfungen, die später zu Problemen führen.
Retrospektives Format: Geliefert / Blockiert / Überarbeitung / Zusammenarbeit
Dieses Format konzentriert sich auf die Ausführungsgesundheit. „Delivered“ feiert den Fortschritt. „Blockiert“ bringt systemische Hindernisse zum Vorschein. „Nacharbeiten“ verfolgt, wo das Team Arbeit wiederholen musste (ein führender Indikator für Prozessprobleme). „Collaboration“ untersucht, wie gut verschiedene Funktionen zusammenarbeiten.
Zu stellende Fragen:
- Wo haben sich die Anforderungen nach Beginn der Entwicklung geändert und warum?
- Welche Überarbeitung wurde in diesem Sprint vorgenommen und was hat sie verursacht?
- Gab es Entscheidungen, auf die wir warten mussten und die uns ausgebremst haben?
- Stimmt der Umfang noch mit dem überein, was wir bei der Entdeckung gelernt haben?
Worauf Sie achten sollten:
In der Build-Phase verlieren Teams am häufigsten den Bezug zum „Warum“ hinter dem, was sie bauen. Retrospektiven sollten regelmäßig überprüfen, ob das Team immer noch Klarheit über das Problem hat, das es löst, und nicht nur über die Funktionen, die es ausliefert.
Achten Sie auf Nacharbeitsmuster. Wenn die gleichen Arten von Problemen immer wieder zu Nacharbeiten führen (unklare Akzeptanzkriterien, fehlende Grenzfälle, Abweichungen zwischen Design und Code), sollten Ihre retrospektiven Maßnahmen auf die Grundursache abzielen und nicht nur das Symptom erneut notieren.
Stufe 3: Einführung – funktionsübergreifende Koordinierung
Der Start ist eine koordinative Herausforderung. Technik, Produkt, Design, Marketing, Vertrieb und Support müssen alle ihre Teile der Reihe nach ausführen. Das größte Risiko ist nicht ein Fehler im Code; Es ist eine Lücke zwischen Funktionen, durch die etwas durchfällt.
Retrospektives Format: Geplant / Ist / Lücke / Nächstes Mal
Dieses Format ist bewusst vergleichend. Sie legen dar, was der Plan war, was tatsächlich passiert ist, wo die Lücken waren und was Sie für den nächsten Start ändern würden. Das funktioniert gut, weil die Einführungen so konkret sind, dass Sie genau sagen können, was vom Plan abgewichen ist.
Zu stellende Fragen:
- Wo ist der Plan gescheitert und war es ein Planungsfehler oder ein Ausführungsfehler?
- Welche funktionsübergreifenden Übergaben verliefen reibungslos und welche nicht?
- Haben die Kunden so reagiert, wie wir es erwartet haben? Was hat uns überrascht?
- Was haben wir in der ersten Woche gelernt, was wir gerne früher gewusst hätten?
Wann soll es ausgeführt werden:
Warten Sie nicht zu lange. Führen Sie innerhalb einer Woche nach der Veröffentlichung eine kurze Retrospektive durch, solange die Details aktuell sind. Wenn es sich um einen bedeutenden Start handelt, führen Sie nach 30 Tagen einen zweiten Start durch, sobald Sie über echte Nutzungsdaten verfügen. Der erste Retro fängt Koordinationsprobleme ein. Die zweite Methode erfasst Signale zur Produkt-Markt-Passung.
Worauf Sie achten sollten:
Bei Launch-Retrospektiven kommt es oft zu Schuldzuweisungen, wenn etwas schiefgeht. Geben Sie frühzeitig den Ton an: Das Ziel besteht darin, den Startvorgang zu verbessern, und nicht darin, herauszufinden, wer den Ball fallen gelassen hat. Rahmenlücken als Systemfehler, nicht als Einzelfehler. „Unser Prozess enthielt keinen Schritt für X“ ist nützlicher als „Person Y hat vergessen, X auszuführen.“
Stufe 4: Iterieren – Entscheiden Sie, was mehr Investitionen verdient
Nach der Einführung beobachten Sie die Nutzungsdaten und entscheiden, wo Sie weiter investieren. Einige Funktionen werden sich durchsetzen und verdienen eine Erweiterung. Andere werden schlechter abschneiden und müssen überdacht oder gekürzt werden. Das größte Risiko in dieser Phase ist der Irrtum der versunkenen Kosten: weiterhin in etwas zu investieren, nur weil man es bereits gebaut hat.
Retrospektives Format: Arbeiten / Nicht funktionieren / Verdoppeln / Loslassen
Dieses Format erzwingt explizite Priorisierungsentscheidungen. „Funktioniert“ und „Funktioniert nicht“ basieren auf tatsächlichen Nutzungsdaten und Feedback, nicht auf dem Bauchgefühl. „Double Down“ und „Let Go“ übersetzen Beobachtungen in Entscheidungen zur Ressourcenzuweisung.
Zu stellende Fragen:
- Welche Funktionen nutzen Kunden tatsächlich und welche ignorieren sie?
- Wo investieren wir Anstrengungen, die keine angemessenen Ergebnisse liefern?
- Welche Signale würden uns sagen, dass es an der Zeit ist, mit dem Iterieren aufzuhören und weiterzumachen?
- Iterieren wir auf ein lokales Maximum zu oder gibt es eine größere Chance, die wir verpassen?
Worauf Sie achten sollten:
Teams wehren sich oft gegen die Spalte „Loslassen“. Es besteht eine emotionale Bindung zu Funktionen, an denen sie hart gearbeitet haben. Der Moderator muss den Sonnenuntergang als einen gesunden Teil der Produktentwicklung und nicht als Misserfolg normalisieren. Für jede Funktion, die Sie behalten, fallen laufende Wartungskosten an. Ehrlich zu sagen, was nicht funktioniert, gibt Kapazitäten für Dinge frei, die funktionieren.
Bühnenspezifische Retrospektiven in der Praxis durchführen
Sie müssen hierfür kein aufwändiges System aufbauen. Hier sind die praktischen Schritte:
1. Benennen Sie Ihre aktuelle Phase. Geben Sie zu Beginn jeder Retrospektive explizit an, in welcher Phase sich das Team befindet. Das klingt offensichtlich, aber viele Teams tun es nie und es gibt dem gesamten Gespräch einen neuen Rahmen.
2. Wählen Sie das richtige Format. Verwenden Sie die oben genannten Formate als Ausgangspunkte und passen Sie sie an Ihren Kontext an. Die spezifischen Spaltennamen sind weniger wichtig als die Frage, ob das Format die Aufmerksamkeit auf die richtigen Fragen für Ihre aktuelle Phase lenkt.
3. Wechseln Sie bewusst. Wenn Sie von einer Phase zur nächsten wechseln (z. B. von der Entdeckung zum Build), führen Sie einen „Retro-Übergang“ durch, der auf die vorherige Phase zurückblickt und Erwartungen für die nächste festlegt. Dies ist ein natürlicher Moment, um sich auf Ziele und Erfolgskennzahlen neu auszurichten.
4. Halten Sie die Maßnahmen bühnengerecht. Bei einem Discovery-Maßnahme sollte es darum gehen, die Art und Weise zu verbessern, wie Sie lernen. Bei einem Build-Maßnahme sollte es darum gehen, Ihre Ausführung zu verbessern. Wenn Ihre Maßnahmen nicht zu Ihrer Phase passen, erfüllt das Retrospektivformat seinen Zweck nicht.
5. Überprüfen Sie alle Phasen an Meilensteinen. Führen Sie nach einem vollständigen Zyklus von der Entdeckung bis zur Iteration eine Meta-Retrospektive durch, in der untersucht wird, wie der Gesamtprozess funktioniert hat. Hier verbessern Sie Ihren Produktentwicklungsprozess selbst und nicht nur die Arbeit innerhalb einer einzelnen Phase.
Häufige Fehler, die es zu vermeiden gilt
Verwendung von Build-Metriken während der Entdeckung. Geschwindigkeit und Story Points sind irrelevant, wenn das Ziel das Lernen ist. Die Messung der Entdeckung anhand der Liefergeschwindigkeit fördert den vorzeitigen Aufbau.
Die Einführungs-Retrospektive überspringen. Teams sind nach einer Einführung oft erschöpft und überspringen die Retrospektive. Genau dann ist die Retro am wertvollsten, denn Koordinationsprobleme sind frisch und spezifisch.
Iteration als unendlich behandeln. Jeder Iterationszyklus sollte einen klaren Entscheidungspunkt haben: erweitern, beibehalten oder untergehen. Wenn Ihre Retrospektiven während der Iteration nie zu einer „Loslassen“-Entscheidung führen, sind Sie wahrscheinlich nicht ehrlich, was die Daten Ihnen sagen.
Nicht die richtigen Leute einbeziehen. Discovery-Retros brauchen Forscher und Designer im Mittelpunkt. Launch-Retros brauchen Marketing und Unterstützung. Laden Sie die Leute ein, die tatsächlich die Arbeit für diese Phase erledigen.
Probieren Sie NextRetro kostenlos aus – Richten Sie in wenigen Minuten bühnenspezifische Retrospektivtafeln mit anpassbaren Spalten und integrierten Vorlagen ein.
Letzte Aktualisierung: Februar 2026
Lesezeit: 7 Minuten
