# Sprint Review: Vom Vorführen zum Entscheiden

Autor: Marin Niehues, Niehues Consulting · Veröffentlicht: 2024-02-05 · Delivery & Steuerung
Quelle: https://www.niehuesconsulting.de/blog/sprint-review-vorfuehren-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?

**Ein Sprint Review ist gelungen, wenn danach mindestens eine Entscheidung zu Inhalt, Reihenfolge oder Zeitplan des Product Backlog gefallen ist. Eine Demonstration ohne Entscheidung ist Berichterstattung.**

## 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](/blog/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](/blog/product-owner-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.

**Reifegradmodell des Sprint Reviews**
Reifegrad | Merkmal | Typisches Symptom | Nächster Schritt
1 Statusrunde | Das Team berichtet Fortschritt in Prozent und Aufgaben | Stakeholder hören zu, niemand ändert etwas am Product Backlog | Fertige Ergebnisse am laufenden Produkt zeigen
2 Vorführung | Das Team zeigt fertige Funktionen am laufenden Produkt | Beifall und vereinzelte Wünsche, die ohne Folge bleiben | Rückmeldungen am Product Backlog festhalten
3 Rückmelderunde | Stakeholder probieren aus, Rückmeldungen landen im Product Backlog | Das Backlog wächst, die Reihenfolge bleibt gleich | Entscheidungen zu Reihenfolge und Umfang einplanen
4 Entscheidungsrunde | Die Runde ändert Reihenfolge, Umfang oder Termin und hält das fest | Das Product Backlog sieht nach jedem Review anders aus | Wirkung der Entscheidungen an Kennzahlen messen
Mit Niehues Consulting | Reifegrad wird zu Beginn gemessen, danach klärt das Team Rollen und Entscheidungswege | Fehlende Entscheider und unklare Zuständigkeiten | Review an Geschäftsergebnis und Kennzahlen koppeln

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](/blog/release-planung-termine-zusagen-halten/).

**Prüfliste für das nächste Sprint Review**
- Sind alle Personen eingeladen, die in den nächsten zwei Wochen etwas am Product Backlog ändern können?
- Wird am laufenden Produkt gearbeitet, und können Stakeholder selbst ausprobieren?
- Sind nicht fertige Einträge benannt, und wird nichts als fertig gezeigt, was die Definition of Done verfehlt?
- Hält ein Protokollant jede Rückmeldung am Product Backlog fest?
- Endet die Sitzung mit mindestens einer Entscheidung, die der Product Owner laut bestätigt?
- Hat jeder offene Punkt einen Verantwortlichen und ein Datum?

## 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](/#kontakt) vereinbaren.

**Fazit**
Das Sprint Review prüft das Ergebnis des Sprints und bringt die Entscheidungen hervor, die das Product Backlog verändern. Es gelingt, wenn die Entscheider im Raum sind, am laufenden Produkt gearbeitet wird und die Sitzung mit einer bestätigten Entscheidung endet. Der Reifegrad des Reviews zeigt, ob das Team vorführt oder steuert.

**Grundlage**
- Schwaber, Sutherland: The Scrum Guide, Abschnitt Sprint Review, Leitfaden, 2020

## Häufige Fragen

### Was ist ein Sprint Review?

Ein Sprint Review ist das Scrum-Ereignis am Ende des Sprints, in dem das Scrum Team und die wichtigsten Stakeholder das Ergebnis prüfen und Anpassungen festlegen. Es ist eine Arbeitssitzung zum Product Backlog. Die Retrospektive folgt danach.

### Was ist der Unterschied zwischen Sprint Review und Sprint Demo?

Eine Sprint Demo zeigt Ergebnisse, ein Sprint Review bewertet sie und leitet Entscheidungen ab. Die Demonstration am laufenden Produkt ist ein Teil des Reviews. Der Scrum Guide 2020 beschreibt das Review ausdrücklich als Arbeitssitzung und nicht als Präsentation.

### Wie lange dauert ein Sprint Review?

Ein Sprint Review dauert höchstens vier Stunden bei einem Sprint von einem Monat, bei kürzeren Sprints entsprechend weniger. Bei zweiwöchigen Sprints sind ein bis zwei Stunden üblich. Entscheidend ist, dass am Ende Zeit für die Entscheidungen bleibt.

### Wer muss beim Sprint Review dabei sein?

Dabei sein müssen das gesamte Scrum Team und die Stakeholder, die über Inhalt und Reihenfolge des Product Backlog mitentscheiden. Reine Beobachter erhalten besser eine Zusammenfassung. Fehlt der Entscheider, entstehen Wünsche ohne Wirkung.

### Wer leitet das Sprint Review?

Das Scrum Team veranstaltet das Review gemeinsam, der Scrum Guide nennt keine einzelne Leitung. In der Praxis führt der Product Owner inhaltlich, weil er Product Backlog und Wert verantwortet, und der Scrum Master sorgt dafür, dass das Ereignis stattfindet und im Zeitrahmen bleibt.

### Was passiert mit nicht fertigen Einträgen im Review?

Nicht fertige Einträge werden im Review benannt, aber nicht als Ergebnis gezeigt. Sie kehren ins Product Backlog zurück, und der Product Owner entscheidet über ihre Reihenfolge neu. Ein Eintrag gilt nur dann als fertig, wenn er die Definition of Done erfüllt.

### Wie bereiten Sie ein Sprint Review vor?

Sie bereiten ein Sprint Review vor, indem Sie das laufende Produkt in einen vorführbaren Zustand bringen, die Teilnehmerliste prüfen und die Fragen an die Stakeholder festlegen. Der Product Owner bringt das aktuelle Product Backlog mit. Folien sind nicht nötig.

### Wie messen Sie, ob Ihr Sprint Review wirkt?

Ein Sprint Review wirkt, wenn sich das Product Backlog nach jedem Termin nachvollziehbar verändert. Als Kennzahl eignet sich die Zahl der Entscheidungen je Review und der Anteil der Rückmeldungen, die im Backlog landen. Das Reifegradmodell in diesem Beitrag liefert dazu die Einordnung.