Retrospektive (Scrum)

Die Retrospektive (Scrum) schafft einen festen Rahmen, in dem das gesamte Scrum-Team den zurückliegenden Sprint auswertet. Die englische Bezeichnung lautet Sprint Retrospective. Im Mittelpunkt stehen Arbeitsweise und Zusammenarbeit, nicht die fachliche Bewertung des entwickelten Produkts. Die Retrospektive findet nach der Sprint Review und vor der nächsten Sprint-Planung statt.

Was eine Scrum-Retrospektive leistet

Eine Scrum-Retrospektive untersucht, wie Personen, Kommunikation, Prozesse, Werkzeuge und die Definition of Done zusammengewirkt haben. Die Definition of Done beschreibt die verbindlichen Qualitätskriterien, die ein Arbeitsergebnis erfüllen muss. Das Team betrachtet Erfolge ebenso wie Schwierigkeiten und sucht nach Ursachen, die es selbst beeinflussen kann.

Der verbreitete Denkfehler besteht darin, die Retrospektive als allgemeine Feedbackrunde zu behandeln. Eine offene Aussprache allein verändert den nächsten Sprint noch nicht. Eine Retrospektive liefert erst dann einen operativen Nutzen, wenn das Team aus seinen Beobachtungen mindestens eine konkrete Maßnahme ableitet, eine Zuständigkeit festlegt und die Umsetzung im folgenden Sprint überprüft.

• Beobachtungen beschreiben, ohne Personen zu bewerten.
• Ursachen statt einzelner Symptome untersuchen.
• Verbesserungen nach Nutzen und Umsetzbarkeit priorisieren.
• Wenige Maßnahmen mit klarer Zuständigkeit beschließen.

Ablauf einer Retrospektive

Eine Retrospektive folgt keinem verbindlich vorgeschriebenen Moderationsformat. Bewährt hat sich ein Ablauf mit fünf Phasen: Gespräch eröffnen, Informationen sammeln, Zusammenhänge untersuchen, Maßnahmen auswählen und das Treffen abschließen. Der Scrum Master unterstützt den Prozess und achtet darauf, dass alle Mitglieder des Scrum-Teams zu Wort kommen.

Rahmen und Sicherheit schaffen

Die erste Phase klärt Ziel, Zeitrahmen und Gesprächsregeln. Aussagen sollten sich auf beobachtbares Verhalten oder konkrete Ereignisse beziehen. Eine Formulierung wie „Die Freigabe erfolgte erst am letzten Sprint-Tag“ ist prüfbar. Eine Aussage wie „Die Abstimmung war schlecht“ bleibt dagegen zu ungenau, um daraus eine belastbare Verbesserung abzuleiten.

Daten und Ursachen untersuchen

In der zweiten und dritten Phase sammelt das Team Fakten aus dem Sprint. Dazu gehören Verzögerungen, ungeplante Aufgaben, Übergaben, Rückfragen, Qualitätsprobleme oder besonders gut funktionierende Abläufe. Anschließend prüft das Team, welche Bedingungen diese Ergebnisse verursacht oder begünstigt haben. Methoden wie Start, Stop, Continue oder Mad, Sad, Glad strukturieren diese Diskussion.

Maßnahmen verbindlich festlegen

In der vierten Phase wählt das Scrum-Team wenige Verbesserungen aus, die es im nächsten Sprint tatsächlich umsetzen kann. Eine geeignete Maßnahme benennt Handlung, Zuständigkeit und Prüfkriterium. „Kommunikation verbessern“ ist zu allgemein. „Für jede neue Landingpage findet vor der Texterstellung ein 15-minütiger Abstimmungstermin zwischen SEO und Redaktion statt“ lässt sich eindeutig umsetzen und überprüfen.

Retrospektive im Online-Marketing

Eine Retrospektive lässt sich auch in SEO-, SEA-, GEO- und Content-Projekten nutzen, wenn Teams in regelmäßigen Arbeitszyklen planen. Nach einem Content-Sprint kann das Team beispielsweise untersuchen, warum Freigaben länger dauerten, Briefings Rückfragen erzeugten oder technische Anforderungen erst nach der Texterstellung auffielen. Der Fokus liegt auf dem Prozess, nicht auf einer isolierten Ranking-Veränderung.

Eine kurze Beobachtung aus Agenturprojekten: Retrospektiven liefern häufig bessere Maßnahmen, wenn operative Daten vor dem Termin vorliegen. Dazu zählen Bearbeitungszeiten, offene Freigaben, verspätete Aufgaben und dokumentierte Rückfragen. Ein automatisiertes SEO-Reporting kann Ergebnisdaten bereitstellen, ersetzt aber nicht die gemeinsame Bewertung ihrer Ursachen.

Für interne Marketing-Abteilungen eignet sich die Retrospektive zudem als Baustein einer strukturierten Inhouse-SEO-Organisation. Wiederkehrende Arbeitszyklen machen sichtbar, ob Zuständigkeiten, Freigaben und Schnittstellen funktionieren. Messbar ist die Umsetzung zum Beispiel über die Maßnahmenquote: umgesetzte Maßnahmen geteilt durch beschlossene Maßnahmen, multipliziert mit 100. Werden drei von vier Maßnahmen abgeschlossen, beträgt die Quote 75 Prozent.

Abgrenzung zu Scrum-Terminen

Der Unterschied zwischen Retrospektive und Sprint Review liegt im Prüfgegenstand. Die Sprint Review betrachtet das Produktinkrement und mögliche Anpassungen des Product Backlogs. Die Retrospektive untersucht dagegen die Arbeitsweise des Scrum-Teams und plant Verbesserungen für Qualität und Effektivität.

Lessons Learned werden häufig am Ende eines gesamten Projekts gesammelt und dienen vor allem dem Wissenstransfer. Eine Scrum-Retrospektive findet nach jedem Sprint statt und beeinflusst unmittelbar den nächsten Arbeitszyklus. Dadurch entsteht eine laufende Verbesserungsschleife, statt Erkenntnisse erst nach Projektabschluss zu dokumentieren.

Typische Fehler bei Retrospektiven

Eine Retrospektive verliert ihren Nutzen, wenn dieselben Probleme wiederholt besprochen werden, ohne dass Maßnahmen umgesetzt werden. Ebenso problematisch sind zu viele Aufgaben, unklare Zuständigkeiten oder Diskussionen über Themen außerhalb des Einflussbereichs des Teams. Prüfe zu Beginn jedes Treffens den Status der zuletzt beschlossenen Maßnahmen.

Für Marketing-Teams sind außerdem fehlende Daten und vermischte Ziele typische Fehler. Eine Retrospektive über Content-Prozesse sollte Bearbeitungszeiten und Freigaben untersuchen, während ein separates Performance-Review Rankings, Leads oder Kosten bewertet. Unternehmen, die solche Abläufe umfassender strukturieren möchten, können eine SEO- und SEA-Beratung mit klarer Prozessanalyse nutzen.

Häufige Fragen zur Scrum-Retrospektive

Wenn du Abläufe in SEO-, SEA- oder GEO-Projekten strukturiert überprüfen möchtest, kann ein unverbindliches Erstgespräch die passenden Ansatzpunkte klären.

Kostenlosen Potenzialcheck anfragen