Ablauf & Teilnehmer des Sprint Reviews – Ein Sprint Review ist eines der am häufigsten missverstandenen Scrum-Events – und gleichzeitig eines der wirksamsten, wenn es richtig durchgeführt wird. Viele Teams degradieren es zu einer Folienpräsentation, in der Statusberichte vorgelesen werden. Damit verschenken sie die größte Chance auf echtes Feedback, Kurskorrekturen und Stakeholder-Alignment. In diesem Beitrag erfahren Sie, wie der Ablauf eines Sprint Reviews Schritt für Schritt aussieht, wer zwingend teilnehmen sollte und wie Sie das Meeting so gestalten, dass es für Management, Fachbereiche und Entwicklungsteams gleichermaßen wertstiftend ist.
Was ist ein Sprint Review?
Ein Sprint Review ist ein zentrales Ereignis in Scrum, bei dem das Scrum Team gemeinsam mit relevanten Stakeholdern das Ergebnis des Sprints – das Increment – begutachtet und die nächsten Schritte plant.
Kurz gesagt:
Im Sprint Review wird geprüft, was im Sprint erreicht wurde, welches Feedback es dazu gibt und wie das Product Backlog und die Planung auf Basis dieses Feedbacks angepasst werden.
Wesentliche Merkmale:
- Fokus auf dem Produkt-Inkrement, nicht auf individuellen Leistungen
- Interaktives Meeting mit Dialog, nicht Einweg-Präsentation
- Ziel: Inspektion und Anpassung von Produkt, Zielen und Roadmap
- Fester Zeitpunkt: am Ende jedes Sprints
Ziele und Nutzen des Sprint Reviews
Damit Sie den Ablauf sinnvoll gestalten können, ist wichtig zu verstehen, welche Ziele ein Sprint Review verfolgt. Typische Fragen sind: „Wozu braucht man das Sprint Review überhaupt?“ oder „Was wird im Sprint Review entschieden?“.
Zentrale Ziele:
- Transparenz schaffen
- Was wurde im Sprint tatsächlich geliefert?
- In welchem Zustand ist das Produkt-Inkrement?
- Feedback einholen
- Fachliche Einschätzungen von Stakeholdern
- Markt- oder Nutzerfeedback berücksichtigen
- Product Backlog prüfen und anpassen
- Sind Prioritäten noch richtig?
- Müssen Anforderungen ergänzt, geändert oder gestrichen werden?
- Nächste Schritte grob planen
- Was ist ein sinnvoller nächster Fokus?
- Welche Risiken und Chancen haben sich gezeigt?
Nutzen für die Organisation:
- Bessere Ausrichtung auf Geschäftsziele
- Frühe Erkennung von Fehlentwicklungen
- Höhere Akzeptanz bei Stakeholdern durch regelmäßige Einbindung
- Mehr Verbindlichkeit und Fokus im Scrum Team
Wer nimmt am Sprint Review teil?
Eine der häufigsten Praxisfragen lautet: „Wer sollte beim Sprint Review dabei sein?“
Die Teilnehmerzusammensetzung entscheidet maßgeblich über den Wert des Meetings. Grundsätzlich gilt:
Alle, die fundiertes Feedback zum Inkrement geben oder relevante Entscheidungen für die weitere Richtung des Produkts treffen können, sollten am Sprint Review teilnehmen.
Im Detail:
Product Owner
Der Product Owner ist fachlich verantwortlich für den Wert des Produkts und steht im Sprint Review im Zentrum.
Aufgaben:
- Erläutert das Sprint-Ziel und den aktuellen Produktstand
- Zeigt, welche Backlog Items als „Done“ gelten
- Nimmt Feedback auf und übersetzt es in Anpassungen des Product Backlogs
- Priorisiert gemeinsam mit Stakeholdern die nächsten Ziele
Scrum Master
Der Scrum Master stellt sicher, dass das Sprint Review dem Scrum-Rahmen entspricht und effizient abläuft.
Aufgaben:
- Moderiert oder unterstützt die Moderation
- Achtet auf Timebox, Fokus und Interaktivität
- Hilft, Dysfunktionen zu erkennen (z. B. Monologe, Schuldzuweisungen)
- Sorgt für ein konstruktives Arbeitsklima
Entwicklungsteam (Developers)
Das Entwicklungsteam (Developers im Scrum Guide) präsentiert das Inkrement und beantwortet Detailfragen.
Aufgaben:
- Zeigt fertige Funktionalitäten anhand von Live-Demos
- Beantwortet technische und fachliche Fragen
- Liefert Transparenz über Einschränkungen, Annahmen, Risiken
- Diskutiert gemeinsam mit Stakeholdern Umfang und Qualität
Wichtig: Das Sprint Review ist kein Rechtfertigungsmeeting für das Team, sondern ein gemeinsamer Inspektions- und Anpassungsworkshop.
Stakeholder
Stakeholder sind alle Personen außerhalb des Scrum Teams, die ein legitimes Interesse am Produkt haben, z. B.:
- Fachbereichsvertreter
- Kunden oder Nutzungsvertreter (z. B. Key User)
- Management, Produktverantwortliche, Business Owner
- Vertreter von Vertrieb, Operations, Support
Rolle der Stakeholder:
- Geben fachliches, geschäftliches und nutzerzentriertes Feedback
- Bewerten Business Value, Risiken, Akzeptanz
- Bringen Marktperspektive und strategische Ziele ein
- Diskutieren mit dem Product Owner Prioritäten und Roadmap
Optionale Teilnehmer
Je nach Kontext können zusätzlich sinnvoll sein:
- UX-/UI-Designer
- Data-Analysten
- Architekten
- Vertreter anderer Teams bei Abhängigkeiten
Sie sollten aber immer klar sein:
Nur Personen, die aktiv beitragen, sollten teilnehmen – reine Zuhörer-„Zuschauerreihen“ verwässern das Format.
Ablauf des Sprint Reviews: Schritt-für-Schritt
Wie läuft ein Sprint Review konkret ab? Folgende Struktur hat sich in vielen Organisationen bewährt (für einen zweiwöchigen Sprint, Timebox z. B. 1,5–2 Stunden):
1. Vorbereitung (vor dem Meeting)
Gute Sprint Reviews beginnen nicht erst mit der Begrüßung.
Typische Vorbereitungen:
- Product Owner
- Aktualisiert das Product Backlog
- Klärt, welche Product Backlog Items „Done“ sind
- Strukturiert die Story-Reihenfolge für die Demo
- Entwicklungsteam
- Stellt sicher, dass das Inkrement in produktionsnahem Umfeld demonstrierbar ist
- Bereitet kurze, fokussierte Demoszenarien vor
- Scrum Master
- Klärt Agenda, Teilnehmerkreis und Logistik
- Stellt sicher, dass Remote-Teilnahme (falls nötig) technisch sauber funktioniert
2. Einstieg: Begrüßung und Zielklärung
Zu Beginn sollte der Rahmen bewusst gesetzt werden:
- Kurze Begrüßung durch Product Owner oder Scrum Master
- Erläuterung:
- Ziel des Meetings: Inspektion des Inkrements und gemeinsame Planung der nächsten Schritte
- Agenda und Timebox
- Optional: Kurzer Business-Kontext
- Wichtige Ereignisse seit dem letzten Review (z. B. Marktentwicklungen)
3. Rückblick auf das Sprint-Ziel und -Umfang
Anschließend wird der Sprint kurz in Erinnerung gerufen:
- Was war das Sprint-Ziel?
- Welche Product Backlog Items wurden geplant?
- Welche davon sind „Done“, welche nicht – und warum?
Wichtig:
Es geht um Transparenz und Lernchancen, nicht um Schuldzuweisungen.
Eine einfache Darstellung (z. B. Tabelle, Board) hilft:
- Geplante Items
- Realisiert („Done“)
- Nicht fertiggestellt (mit kurzer, sachlicher Begründung)
4. Präsentation des Produkt-Inkrements (Live-Demo)
Dies ist der Kern des Sprint Reviews. Statt Folien mit Screenshots sollte das Team das Produkt live zeigen:
Empfehlungen für eine gute Demo:
- Szenarien aus Sicht der Nutzer zeigen, nicht technisch-organisiert („Kunde legt Bestellung an“ statt „Ticket #123 implementiert“)
- Kurze, fokussierte Flows statt Vollständigkeits-Marathon
- Zeigen, wie neue Funktionalität Business Value stiftet:
- Was wird für Nutzer leichter, schneller, sicherer?
- Wenn sinnvoll: Vorher/Nachher-Vergleiche
Während der Demo:
- Stakeholder werden aktiv ermutigt, Fragen zu stellen und Feedback zu geben
- Das Team dokumentiert relevante Erkenntnisse und Wünsche (für spätere Bewertung, nicht zur sofortigen Zusage)
5. Gemeinsame Diskussion und Feedback
Nach (oder begleitend zur) Demo ist Raum für strukturierte Diskussion. Typische Leitfragen:
- Erfüllt die Funktionalität die fachlichen Erwartungen?
- Welche Risiken, offenen Punkte oder Unklarheiten sehen Stakeholder?
- Welche neuen Chancen oder Ideen ergeben sich?
- Gibt es Auswirkungen auf andere Bereiche / Prozesse?
Hier ist wichtig:
- Feedback wird offen angenommen, nicht verteidigt
- Der Product Owner bewertet direkt oder im Nachgang, welche Punkte ins Backlog einfließen
- Es werden keine übereilten Zusagen gemacht („Das ist im nächsten Sprint auf jeden Fall drin“), bevor Aufwand und Priorität klar sind
6. Anpassung und Ausblick auf das Product Backlog
Auf Basis der Erkenntnisse wird die weitere Produktentwicklung grob skizziert. Typische Inhalte:
- Kurzer Blick auf das aktuelle Product Backlog und die Roadmap
- Welche Items sind nach heutigem Stand am wichtigsten?
- Welche Prioritäten haben sich geändert?
- Welche neuen Backlog-Einträge entstehen aus dem Review?
Wichtig:
Das Sprint Review ist keine vollständige Backlog Refinement-Session. Es geht um gemeinsames Verständnis und grobe Richtung, nicht um detaillierte Ausarbeitung jeder Story.
7. Abschluss und nächste Schritte
Am Ende werden die wichtigsten Punkte zusammengefasst:
- Welche Entscheidungen wurden getroffen?
- Welche neuen Erkenntnisse gab es?
- Was bedeutet das für die nächsten Sprints?
Optional kann der Product Owner kurz skizzieren:
- Vermuteter Fokus des nächsten Sprints (ohne dessen Planung vorwegzunehmen)
- Anstehende wichtige Meilensteine
Danach endet das Sprint Review – und das Team bereitet sich auf die Sprint Retrospektive und anschließend die nächste Sprint Planning vor.
Praxisbeispiel: Zeitstruktur für ein 2‑Stunden-Sprint-Review
Für einen zweiwöchigen Sprint mit 2-Stunden-Review kann ein typischer Ablauf so aussehen:
- 0–10 Minuten
- Begrüßung, Ziele, Agenda, Business-Kontext
- 10–25 Minuten
- Rückblick auf Sprint-Ziel, geplante vs. abgeschlossene Items
- 25–75 Minuten
- Live-Demo des Inkrements (Nutzerflows), unmittelbare Fragen
- 75–105 Minuten
- Strukturierte Feedback- und Diskussionsrunde
- Identifikation neuer Anforderungen und Risiken
- 105–115 Minuten
- Blick auf Product Backlog & Roadmap, grober Ausblick
- 115–120 Minuten
- Zusammenfassung, klare nächste Schritte, Verabschiedung
Diese Struktur ist ein Leitfaden, kein Dogma. Entscheidend ist, dass der größte Teil der Zeit auf Inspektion des Inkrements und interaktive Diskussion entfällt.
Sprint Review vs. Sprint Retrospektive
Häufig werden Sprint Review und Sprint Retrospektive verwechselt. Kurz zur Einordnung:
- Sprint Review
- Fokus: Produkt und Ergebnisse des Sprints
- Teilnehmer: Scrum Team + Stakeholder
- Inhalte: Inkrement, Feedback, Product Backlog, nächste Schritte
- Sprint Retrospektive
- Fokus: Zusammenarbeit, Prozesse, Werkzeuge
- Teilnehmer: Nur Scrum Team
- Inhalte: Was lief gut, was nicht, was verbessern wir konkret?
Wichtige Konsequenz:
Diskussionen über Teamkonflikte, interne Arbeitsweisen oder Tooling gehören nicht ins Sprint Review, sondern in die Retrospektive.
Best Practices für wirksame Sprint Reviews
Damit das Sprint Review seinen vollen Nutzen entfaltet, haben sich folgende Prinzipien bewährt:
1. Live statt PowerPoint
- Möglichst direkt im Produkt demonstrieren
- Nur unterstützende Visualisierungen verwenden, keine Folien-Schlachten
2. Nutzerperspektive einnehmen
- Geschichten aus Sicht echter User Journeys erzählen
- Fachbereiche und Stakeholder erkennen ihren Alltag wieder
3. Dialog fördern, nicht monologisieren
- Regelmäßig nachfragen: „Wie passt das für Sie?“
- Pausen für Rückfragen einplanen, nicht alles bis zur letzten Minute durchpräsentieren
4. Klarheit über „Done“ schaffen
- Transparente Definition of Done
- Eindeutig zeigen, welche Items vollständig und qualitativ ausreichend umgesetzt sind
5. Remote-/Hybrid-Format sauber aufsetzen
- Stabile Technik, klare Visualisierung (Board, Backlog, Screenshare)
- Interaktionsmöglichkeiten (Chat, Handzeichen, gemeinsame Whiteboards)
Häufige Fehler im Sprint Review – und wie Sie sie vermeiden
Folgende Muster sehen sich in der Praxis immer wieder:
Statusmeeting statt Review
- Problem: Es werden Zahlen und Fortschrittsbalken präsentiert, aber das Inkrement selbst ist kaum sichtbar.
- Besser: Ergebnis in der Nutzung zeigen, nicht nur Fortschritt berichten.
Keine oder kaum Stakeholder
- Problem: Das Scrum Team sitzt unter sich; Feedback aus Business oder Fachbereich fehlt.
- Besser: Stakeholder aktiv einladen, Nutzen klar kommunizieren und Termin frühzeitig fixieren.
Reine Einweg-Präsentation
- Problem: Stakeholder hören zu, sagen am Ende „passt“ oder „passt nicht“, echter Dialog findet nicht statt.
- Besser: Interaktive Elemente einbauen (Fragen, Diskussionsblöcke, kurze Abstimmungen).
Fehlende Verbindung zu Zielen und Roadmap
- Problem: Niemand erkennt, wie die gelieferten Features zur Gesamtstrategie beitragen.
- Besser: Zu Beginn und am Ende klar zeigen, wie das Inkrement zu Produktvision, Zielen und Kennzahlen beiträgt.
Unklare Nachverfolgung von Feedback
- Problem: Stakeholder geben Input, sehen aber nie, was daraus geworden ist.
- Besser: Im nächsten Sprint Review sichtbar machen, welches Feedback aufgegriffen wurde und wie.
Wichtige W‑Fragen zum Sprint Review auf einen Blick
Zum Abschluss die wichtigsten Fragen und kurze Antworten, wie sie häufig von Führungskräften und Projektverantwortlichen gestellt werden:
Wie oft findet ein Sprint Review statt?
Am Ende jedes Sprints, unabhängig von der Sprintlänge.
Wie lange dauert ein Sprint Review?
Als Richtwert:
Bis zu 4 Stunden für einen einmonatigen Sprint, entsprechend kürzer für kürzere Sprints (z. B. 1,5–2 Stunden bei zwei Wochen).
Wer muss verpflichtend teilnehmen?
Das gesamte Scrum Team (Product Owner, Scrum Master, Developers). Zusätzlich alle relevanten Stakeholder, die Feedback geben oder Entscheidungen beeinflussen.
Was wird im Sprint Review besprochen?
- Was im Sprint erreicht wurde (Inkrement)
- Feedback zum Produktstand
- Anpassung von Product Backlog und Roadmap
- Grobe nächste Schritte
Was wird im Sprint Review nicht besprochen?
- Detaillierte Ursachenanalyse von Teamproblemen
- Individuelle Leistungsbeurteilung
- Vollständige technische Detaildiskussion (nur so weit nötig für Verständnis)
Fazit Ablauf & Teilnehmer des Sprint Reviews: So verankern Sie effektive Sprint Reviews in Ihrer Organisation
Ein gutes Sprint Review ist weit mehr als ein „Abnahme-Meeting“. Es ist der zentrale Ort, an dem Produktentwicklung, Business-Ziele und Nutzerbedürfnisse regelmäßig aufeinander abgestimmt werden.
Wenn Sie
- die richtigen Teilnehmer einbinden,
- einen klaren, produktorientierten Ablauf etablieren,
- echten Dialog und Feedback zulassen und
- die Ergebnisse konsequent im Product Backlog und in der Planung verankern,
wird das Sprint Review zu einem starken Hebel für Transparenz, Wertorientierung und Anpassungsfähigkeit.
Viele Organisationen profitieren in der Einführungs- und Optimierungsphase von externer Unterstützung – insbesondere, wenn mehrere Teams, komplexe Stakeholder-Landschaften oder bestehende Projektstrukturen beteiligt sind. Wenn Sie Sprint Reviews und andere Scrum-Events so gestalten möchten, dass sie echten Mehrwert für Management, Fachbereiche und Entwicklung liefern, kann eine Begleitung durch erfahrene Berater wie die PURE Consultant helfen, passende Formate, Abläufe und Rollenverständnisse in Ihrer Organisation nachhaltig zu verankern.