Checklisten

Checkliste Sprint-Retrospektive

Für: Scrum Master, Teamleads und Teams, deren Retros zur Pflichtübung geworden sind.

Kurz erklärt

Eine Retrospektive wirkt, wenn sie mit ein bis zwei konkreten Massnahmen endet, die im nächsten Sprint als Aufgaben stehen und in der übernächsten Retro geprüft werden. Alles andere — Stimmung, Format, Dauer — ist Mittel zum Zweck. Die häufigste Ursache wirkungsloser Retros: viele Erkenntnisse, keine Verantwortlichen.

Die Retro ist das einzige Meeting, dessen Zweck die Verbesserung des Teams selbst ist. Trotzdem ist sie das erste, das gestrichen wird, wenn es eng wird — meistens, weil sie nichts verändert hat. Das liegt selten am Format und fast immer daran, was nach dem Meeting passiert: nichts.

Zwei Massnahmen, nicht zehn

Eine Retro produziert leicht zehn Verbesserungsideen. Umgesetzt werden davon null, weil alle wichtig sind und keine Priorität hat. Die Disziplin liegt im Weglassen: Was ist die eine Sache, die den nächsten Sprint spürbar besser macht? Die zweite ist Reserve. Der Rest kommt auf eine Liste — und wird beim nächsten Mal neu bewertet.

Psychologische Sicherheit ist die Voraussetzung

Ohne sie werden Symptome besprochen, nie Ursachen. Sicherheit entsteht nicht durch Ansage, sondern durch Erfahrung: Wer einmal offen einen Fehler benannt hat und dafür nicht sanktioniert wurde, tut es wieder. Die Anwesenheit von Vorgesetzten, die nicht Teil des Teams sind, zerstört das zuverlässig — deshalb gehören sie nicht in den Raum.

Retro-Massnahmen sichtbar machen

Massnahmen, die nur im Retro-Protokoll stehen, sterben. Massnahmen, die als Aufgabe im Board stehen, mit Verantwortlichem und Fälligkeit, werden im Daily gesehen. In Flenio lässt sich dafür ein wiederkehrendes «Team-Verbesserung»-Projekt anlegen, in dem jede Retro ihre ein bis zwei Aufgaben ablegt — und die Historie sichtbar bleibt.

Häufige Fragen

Wie lange sollte eine Retro dauern?

Faustregel: 45 Minuten pro Sprint-Woche, maximal 90 Minuten. Wer regelmässig länger braucht, hat zu viele Themen — oder zu wenig Struktur.

Was, wenn immer dieselben Probleme auftauchen?

Dann liegt die Ursache ausserhalb des Teams (Organisation, Abhängigkeiten, Prioritäten) — und die Retro ist der falsche Ort. Als Impediment eskalieren, mit den Retro-Daten als Beleg.

Retro auch ohne Scrum?

Unbedingt. Ein monatlicher Rückblick mit denselben Regeln — Massnahmen, Verantwortliche, Nachverfolgung — funktioniert in jedem Team.