Sprint Review: So führen Sie eines durch (Agenda und Beispiele)

Im Sprint Review zeigt das Team, was es tatsächlich gebaut hat. Gut durchgeführt ist es eine der wertvollsten Stunden in einem Sprint: ein echtes Gespräch zwischen den Menschen, die das Produkt gebaut haben, und denen, die es nutzen oder finanzieren.

Was ist ein Sprint Review?

Ein Sprint Review ist ein formales Scrum-Event, das am Ende jedes Sprints stattfindet. Das Team prüft das Inkrement (alles, was während des Sprints fertiggestellt wurde) und arbeitet mit Stakeholdern zusammen, um den Product Backlog basierend auf den gewonnenen Erkenntnissen anzupassen.

Der Scrum Guide (Schwaber und Sutherland, 2020) definiert es als „Arbeitssitzung" statt als Statusbericht oder Einwegdemo. Diese Unterscheidung ist wichtig. Stakeholder sind kein Publikum, sondern Teilnehmende, die dem Team helfen zu entscheiden, was als Nächstes gebaut wird.

Das Sprint Review ist auf maximal vier Stunden bei einem einmonatigen Sprint zeitlich begrenzt. Kürzere Sprints erhalten proportional kürzere Reviews; die meisten Teams mit zweiwöchigen Sprints halten es bei ein bis zwei Stunden.

Wichtigste Fakten

• Der Scrum Guide (2020) legt eine Vier-Stunden-Zeitbox für einen einmonatigen Sprint fest, die bei kürzeren Sprints entsprechend verkleinert wird.
• Das Sprint Review ist eines von fünf Scrum-Events: Sprint Planning, Daily Scrum, Sprint Review, Sprint-Retrospektive und der Sprint selbst.
• Ein State-of-Agile-Bericht (Digital.ai) aus 2023 ergab, dass 71 % der Befragten Scrum oder einen Scrum-Hybrid einsetzten, womit das Sprint Review zu einem der am weitesten verbreiteten strukturierten Feedback-Meetings in der Softwarebranche zählt.

Eine nützliche Einordnung: Das Sprint Review beantwortet „Haben wir das Richtige gebaut?" Die Sprint-Retrospektive beantwortet „Haben wir es auf die richtige Weise gebaut?"

Sprint Review vs. Sprint-Retrospektive

Diese beiden Events finden am Ende jedes Sprints unmittelbar hintereinander statt, weshalb Teams sie oft vermischen. Es sind grundlegend unterschiedliche Gespräche.

Eine vollständige Aufschlüsselung des Retrospektiven-Formats und der Fragen finden Sie im Leitfaden zur Sprint-Retrospektive.

Wer nimmt an einem Sprint Review teil?

Der Scrum Guide listet folgende Teilnehmende auf:

• Scrum-Team: die Entwickler, die das Inkrement gebaut haben, der Product Owner und der Scrum Master
• Stakeholder: alle, die der Product Owner einlädt, etwa Kunden, Nutzer, Führungskräfte oder Business-Sponsoren
• Fachexperten: optional Spezialisten, deren Input für Entscheidungen über die nächsten Schritte relevant ist

Der Product Owner lädt üblicherweise die Stakeholder ein. Der Scrum Master sorgt dafür, dass das Event produktiv bleibt und innerhalb der Zeitbox abläuft. Entwickler präsentieren das Inkrement und beantworten Fragen direkt. Diese Direktheit ist beabsichtigt. Stakeholder erhalten ungefilterte Informationen; Entwickler erhalten ungefilterte Reaktionen.

Agenda für das Sprint Review

Ein gut strukturiertes Sprint Review durchläuft fünf Teile. Hier eine Beispielagenda für ein 90-minütiges Review (typisch für einen zweiwöchigen Sprint):

Teil 1: Eröffnung (10 Minuten)

Der Product Owner eröffnet mit einem Rückblick auf das Sprint-Ziel und listet die für den Sprint geplanten Punkte auf. Überspringen Sie das nicht. Stakeholder, die nicht beim Sprint Planning dabei waren, brauchen Kontext, bevor sie die Demo sehen.

Teil 2: Inkrement-Demo (40 Minuten)

Entwickler demonstrieren die funktionierende Software. Echte Software, keine Folien. Die Demo sollte sich direkt auf das Sprint-Ziel beziehen und zeigen, dass die Akzeptanzkriterien erfüllt sind. Jedes Feature sollte in einem realistischen Szenario vorgeführt werden, nicht in einer geschönten Durchführung.

Tipp: Weisen Sie jedem Entwickler die Features zu, die er gebaut hat. Er erklärt den Kontext und führt durch die Funktionalität. Das ist glaubwürdiger, als wenn eine Person alles vorführt.

Teil 3: Stakeholder-Feedback (20 Minuten)

Das ist der Kern des Sprint Reviews. Der Product Owner moderiert ein offenes Gespräch. Fragen, die nützliches Feedback anstoßen:

• Löst das Problem, das Sie im Kopf hatten?
• Was würde das nützlicher machen?
• Worauf sollten wir uns als Nächstes konzentrieren?
• Fehlt etwas oder stimmt etwas nicht?

Dokumentieren Sie alles. Stakeholder-Input prägt direkt das nächste Backlog-Update.

Teil 4: Backlog-Review (15 Minuten)

Der Product Owner geht den aktualisierten Product Backlog durch. Hier wird das Gelernte aus dem Sprint in zukünftige Arbeit übersetzt. Neue Punkte tauchen auf. Prioritäten verschieben sich. Team und Stakeholder stimmen sich darüber ab, was als Nächstes am wichtigsten ist.

Teil 5: Abschluss (5 Minuten)

Geben Sie einen Ausblick auf das nächste Sprint-Ziel, bestätigen Sie den nächsten Review-Termin und bedanken Sie sich bei den Stakeholdern. Kurz und klar.

Wie Sie ein wirksames Sprint Review durchführen

Schritt 1: Demo-Umgebung im Voraus vorbereiten

Warten Sie nicht bis zum Morgen des Reviews. Richten Sie eine Staging-Umgebung ein, bestätigen Sie, dass Demo-Konten funktionieren, und testen Sie alle Live-Integrationen am Tag zuvor. Eine kaputte Demo verschwendet die Zeit aller und untergräbt Vertrauen.

Schritt 2: Stakeholder vor dem Meeting briefen

Senden Sie eine kurze Vorabinformation: das Sprint-Ziel, was vorgeführt wird und relevanter Kontext (ein Nutzer-Workflow, den Sie verbessern, ein Bug, den Sie behoben haben). Stakeholder geben besseres Feedback, wenn sie den Ausgangspunkt verstehen.

Schritt 3: Bei funktionierender Software bleiben

Zeigen Sie nur, was gemäß der Definition of Done fertig ist. Ist etwas zu 80 % fertig, führen Sie es nicht vor. Unfertige Arbeit zu zeigen erzeugt Verwirrung und falsch ausgerichtete Erwartungen. Das Inkrement umfasst nur, was dem Standard des Teams für „fertig" entspricht.

Schritt 4: Die richtigen Stakeholder einladen

Mehr ist nicht immer besser. Laden Sie Menschen mit Entscheidungsbefugnis oder direktem Nutzereinblick ein. Eine fokussierte Gruppe von fünf engagierten Personen liefert besseres Feedback als ein passives Publikum von zwanzig.

Schritt 5: Feedback in Echtzeit erfassen

Weisen Sie einer Person zu, den Stakeholder-Input während der Diskussion zu dokumentieren. Umsetzbare Punkte wandern noch vor Sitzungsende direkt in den Backlog, oder werden zumindest markiert, damit der Product Owner sie unmittelbar danach bearbeitet.

Schritt 6: Mit einem klaren nächsten Schritt enden

Bevor der Raum sich leert, nennen Sie den voraussichtlichen Fokus für den nächsten Sprint. Er muss nicht endgültig sein. Aber ohne gemeinsame Richtung auseinanderzugehen, ist eine verpasste Gelegenheit. Das Sprint Review sollte sich anfühlen wie der Abschluss eines Kapitels und der Beginn eines neuen.

Best Practices für das Sprint Review

• Halten Sie die Demo realistisch. Nutzen Sie echte Daten oder möglichst reale Szenarien. Künstliche Demos decken keine echten Usability-Probleme auf.
• Zeitboxen Sie jeden Demo-Abschnitt. Hat ein Team fünf Punkte zu zeigen, teilen Sie die Zeit pro Punkt zu. Ohne Struktur ziehen sich Demos in die Länge, und das Feedback wird zusammengestaucht.
• Wechseln Sie, wer präsentiert. Präsentiert jeder Entwickler seine eigene Arbeit, stärkt das die Teamzuversicht und gibt Stakeholdern ein klareres Bild vom Team.
• Mischen Sie keine Retrospektiven-Themen hinein. Prozessthemen gehören in die Retro. Bringt ein Stakeholder während des Reviews ein Team-Prozessthema zur Sprache, notieren Sie es und verweisen Sie es auf die Retro.
• Halten Sie wichtige Entscheidungen fest. Was haben Stakeholder freigegeben? Was wurde niedriger priorisiert? Welche neuen Anfragen kamen auf? Diese Entscheidungen brauchen eine nachvollziehbare Spur.

Häufige Fehler

Das Review als Einwegdemo behandeln. Schauen Stakeholder nur zu und applaudieren, lassen Sie Wert liegen. Das Sprint Review ist eine gemeinsame Sitzung, keine Theateraufführung.

Features vorführen, die nicht fertig sind. Arbeit in Bearbeitung so zu zeigen, als sei sie vollständig, untergräbt Vertrauen. Ist etwas nicht bereit, sagen Sie es. Lassen Sie es aus, oder zeigen Sie es kurz mit klaren Vorbehalten.

Die Backlog-Diskussion überspringen. Teams, die nur vorführen und dann abbrechen, verpassen den wichtigsten Teil: was sich durch das gerade Gelernte ändert. Die Backlog-Diskussion ist der Punkt, an dem das Ergebnis des Sprints zum Input des nächsten wird.

Es ohne die richtigen Stakeholder durchführen. Ein Sprint Review nur mit internen Teammitgliedern ist lediglich ein Team-Sync. Der Wert entsteht aus externen Perspektiven und echtem Nutzerfeedback.

Keine Vorbereitung. Ad-hoc-Demos scheitern oft oder ziehen sich in die Länge. Eine kurze, am Vortag durchgesehene Vorbereitungs-Checkliste verhindert die meisten Sprint-Review-Katastrophen.

Häufig gestellte Fragen

Was ist ein Sprint Review?

Ein Sprint Review ist ein Scrum-Event am Ende jedes Sprints, bei dem das Team das fertiggestellte Inkrement den Stakeholdern vorführt und Feedback einholt, um den Product Backlog zu aktualisieren. Es ist eine gemeinsame Arbeitssitzung, keine formale Präsentation oder ein Statusbericht.

Wie lange sollte ein Sprint Review dauern?

Der Scrum Guide empfiehlt maximal vier Stunden für einen einmonatigen Sprint. Bei zweiwöchigen Sprints führen die meisten Teams Reviews in ein bis zwei Stunden durch. Die Zeitbox skaliert mit der Sprint-Länge: kürzere Sprints, kürzere Reviews.

Was ist der Unterschied zwischen einem Sprint Review und einer Sprint-Retrospektive?

Das Sprint Review konzentriert sich auf das Produkt: Das Team zeigt, was es gebaut hat, und Stakeholder geben Feedback. Die Sprint-Retrospektive konzentriert sich auf den Prozess des Teams: wie es zusammengearbeitet hat und was zu verbessern ist. Beide finden am Ende des Sprints statt, dienen aber unterschiedlichen Zwecken und haben unterschiedliche Teilnehmende.

Wer leitet das Sprint Review?

Der Product Owner moderiert üblicherweise das Sprint Review, eröffnet die Sitzung und leitet die Backlog-Diskussion. Der Scrum Master sorgt dafür, dass das Event innerhalb der Zeitbox bleibt und produktiv ist. Entwickler präsentieren das Inkrement direkt.

Was passiert, wenn das Sprint-Ziel nicht erreicht wurde?

Das Team führt vor, was fertiggestellt wurde. Unvollständige Punkte werden nicht als fertig präsentiert. Die Lücke zwischen Geplantem und Geliefertem wird zum Input sowohl für das Backlog-Update als auch für die Retrospektive. Transparenz ist hier wertvoller, als zu versuchen, die Ergebnisse schönzureden.

---

Das Sprint Review ist eines der einfachsten Scrum-Events, das man durchführen kann, und eines der am leichtesten schlecht durchgeführten. Eine kurze, gut vorbereitete Demo mit den richtigen Stakeholdern im Raum macht aus jedem Sprint eine echte Feedbackschleife. Und genau das hält Teams dabei, das richtige Produkt zu bauen, nicht nur schnell zu bauen.

Für die anderen Scrum-Events beginnen Sie mit agilen Zeremonien und dem Daily Standup.