Sprint Review: Vom Vorführen zum Entscheiden

Ein Sprint Review dient dazu, das Ergebnis des Sprints zu prüfen und gemeinsam mit den wichtigsten Stakeholdern festzulegen, was als Nächstes angepasst wird. Es ist eine Arbeitssitzung zum Product Backlog und keine Präsentation für Zuschauer. Wer das Review als Vorführung veranstaltet, bekommt Applaus, aber keine Entscheidungen. Dieser Beitrag zeigt nach dem Scrum Guide 2020 den Zweck des Reviews und seinen Ablauf sowie ein Reifegradmodell.

In vielen Unternehmen, die Scrum einsetzen, ist das Sprint Review das sichtbarste Ereignis und zugleich das mit der geringsten Wirkung. Das Team zeigt Funktionen, die Führungskräfte nicken, und der nächste Sprint beginnt mit demselben Product Backlog wie der vorige. Die Lieferperspektive fragt anders: Welche Entscheidung ist nach dem Review getroffen, die vorher offen war?

Was ist der Zweck eines Sprint Reviews?

Der Zweck eines Sprint Reviews ist laut Scrum Guide 2020, das Ergebnis des Sprints zu prüfen und zukünftige Anpassungen festzulegen. Das Scrum Team stellt dazu seine Arbeitsergebnisse den wichtigsten Stakeholdern vor und bespricht den Fortschritt in Richtung des Product Goal. Der Guide beschreibt das Review ausdrücklich als Arbeitssitzung, die das Team nicht auf eine Präsentation beschränken soll. Es ist das zweitletzte Ereignis des Sprints, die Retrospektive folgt danach.

Aus dem Zweck folgen drei Aufgaben. Erstens wird geprüft, was tatsächlich fertig ist. Als fertig gilt ein Inkrement, das die Definition of Done erfüllt, wie der Beitrag zur Definition of Done zeigt. Zweitens bewertet die Runde, was die Ergebnisse für das Product Backlog bedeuten: Welche Einträge ändern sich, welche entfallen, welche rücken nach oben? Drittens bespricht der Product Owner, wie sich Markt und Budget sowie mögliche Liefertermine seit dem letzten Review verändert haben. Der Scrum Guide hält dazu fest, dass das Product Backlog angepasst werden darf, um neue Chancen zu nutzen.

Das Review ist damit der Ort, an dem Lieferung und Steuerung zusammentreffen. Ein Team, das sprintweise liefert, ohne dass jemand mit Entscheidungsgewalt hinschaut, erzeugt Arbeitsstand ohne Steuerung. Und eine Führung, die nur Statusberichte liest, steuert nach Schätzungen statt nach Beobachtung.

Wer nimmt am Sprint Review teil?

Am Sprint Review nehmen das gesamte Scrum Team und die wichtigsten Stakeholder teil. Das Scrum Team besteht aus dem Product Owner und den Entwicklern sowie dem Scrum Master. Als Stakeholder gelten Personen, die vom Ergebnis betroffen sind oder über Budget und Priorität mitentscheiden: Fachbereichsleitung, Anwender mit Entscheidungsrolle, Vertreter angrenzender Teams. Eine Liste, die zu groß wird, verwässert das Gespräch. Eine Liste, in der die Entscheider fehlen, macht das Review zu einer Übung ohne Folgen.

Die Auswahl gelingt mit einer einfachen Regel: Eingeladen wird, wer in den kommenden zwei Wochen etwas am Product Backlog ändern kann oder von einer Änderung unmittelbar betroffen ist. Alle anderen erhalten das Ergebnis als kurze Zusammenfassung. Sinnvollerweise verantwortet der Product Owner die Einladung, denn er steuert den Wert des Produkts und braucht die Rückmeldung der Personen, die ihn bewerten. Wie diese Rolle im Mittelstand besetzt wird, beschreibt der Beitrag zum Product Owner im Mittelstand.

Wie lange dauert ein Sprint Review und wie läuft es ab?

Ein Sprint Review dauert nach dem Scrum Guide höchstens vier Stunden bei einem Sprint von einem Monat und ist bei kürzeren Sprints entsprechend kürzer. In der Praxis sind bei zweiwöchigen Sprints ein bis zwei Stunden üblich. Der Ablauf ist im Guide nicht vorgeschrieben, ein bewährter Rahmen hat fünf Abschnitte.

1. Ausgangslage: Der Product Owner erinnert an das Sprint-Ziel und das Product Goal, damit alle denselben Maßstab anlegen.
2. Ergebnis: Das Team zeigt, was fertig geworden ist, am laufenden Produkt und nicht auf Folien. Nicht fertige Einträge werden benannt und nicht vorgeführt.
3. Rückmeldung: Die Stakeholder probieren aus und stellen Fragen, dann äußern sie, was sie am Ergebnis überzeugt und was ihnen fehlt. Der Moderator hält jede Rückmeldung am Product Backlog fest.
4. Ausblick: Der Product Owner zeigt das Product Backlog mit den neuen Erkenntnissen, die voraussichtliche Reihenfolge und den Stand gegenüber dem Product Goal.
5. Entscheidung: Die Runde legt fest, was sich ändert, und der Product Owner bestätigt die Änderungen laut. Offene Punkte erhalten einen Verantwortlichen und ein Datum.

Der letzte Abschnitt unterscheidet ein Review mit Wirkung von einer Vorführung. Wird er ausgelassen, bleibt das Wissen der Runde im Raum, und der Product Owner muss die Änderungen später mühsam einsammeln.

Wie reif ist Ihr Sprint Review?

Ein Sprint Review lässt sich auf vier Reifegraden einordnen, die aufeinander aufbauen. Die Einordnung zeigt, welcher Schritt als Nächster sinnvoll ist, und verhindert, dass Teams zu früh in Formate springen, für die ihnen die Voraussetzungen fehlen.

Viele Teams starten auf Reifegrad zwei. Der Sprung auf drei gelingt mit Ausprobieren statt Zuschauen: Die Stakeholder bedienen das Produkt selbst, und das Team beobachtet. Der Sprung auf vier verlangt, dass die Entscheider im Raum sind und das Mandat haben, die Reihenfolge zu ändern und den Umfang anzupassen. Fehlt das Mandat, liegt die Ursache in der Organisation, und kein Format des Reviews behebt sie.

Woran scheitert ein Sprint Review?

Drei Ursachen erklären die meisten wirkungslosen Reviews. Die erste ist ein fehlender Entscheider: Die Teilnehmer sind Vertreter ohne Mandat und nehmen Wünsche mit, die in der nächsten Runde wieder verschwinden. Die zweite ist ein Ergebnis, das nicht zeigbar ist. Arbeit an Schnittstellen oder Datenmodellen lässt sich schwer vorführen, und Teams weichen dann auf Folien aus. Wer die Arbeit in Ergebnissen schneidet, die ein Anwender bewerten kann, löst das Problem schon im Planungsgespräch. Die dritte Ursache ist die Angst vor unfertigen Ergebnissen. Wenn ein Team in jedem Review bewertet wird statt beraten, zeigt es nur noch Poliertes, und die Rückmeldung kommt zu spät.

Ein Hinweis auf die Rolle der Führung: Ein Review, das als Abnahme verstanden wird, verliert seine Funktion. Die Abnahme der Qualität regelt die Definition of Done im Sprint. Das Review dient der Frage, ob das Richtige gebaut wird. Wie sich aus Sprint-Ergebnissen Zusagen zu Terminen ableiten lassen, zeigt der Beitrag zur Release-Planung.

Wie unterscheiden sich Sprint Review und Retrospektive?

Das Sprint Review prüft das Produkt, die Retrospektive prüft die Zusammenarbeit. Im Review sitzen das Team und die Stakeholder zusammen, und das Gespräch gilt dem Inkrement und dem Product Backlog. In der Retrospektive bleibt das Scrum Team unter sich und plant Verbesserungen für Qualität und Wirksamkeit seiner Arbeit. Beide Ereignisse beantworten verschiedene Fragen und ersetzen einander nicht.

Sprint Review mit Niehues Consulting

Niehues Consulting ist eine Beratung für KI-Management und Organisationsdesign aus der Lieferperspektive mit Sitz in Düsseldorf. Gründer Marin Niehues baut Organisationen, die liefern, und arbeitet als Delivery Manager und Projektmanager sowie als Product Owner in Projekten von VC-finanzierten Scaleups bis zu DAX-40-Konzernen, in über 20 Ländern auf sechs Kontinenten. Im Leistungsfeld Delivery Management und Organisationsdesign geht es um Rollen und Entscheidungswege sowie Schnittstellen, an denen Reviews in der Praxis hängen bleiben.

Das Vorgehen folgt dem Niehues Delivery Model. Für das Sprint Review zählen zwei Prüffragen: Wer entscheidet, wer liefert, wer nutzt? Welche Rollen braucht der Betrieb, und welche Entscheidungswege und Schnittstellen? Wo diese Antworten fehlen, bleibt jedes Review eine Vorführung, auch bei guter Moderation. Den Einstieg bildet eine kostenfreie Erstberatung von 30 Minuten, die Sie über den Kontakt vereinbaren.