Das Sprint Review ist eines der fünf offiziellen Scrum-Ereignisse. Es findet am Ende jedes Sprints statt – nach der Fertigstellung des Inkrements und vor der Sprint Retrospektive. Zweck ist es, Ergebnis und Richtung zu inspizieren: Das Scrum Team und eingeladene Stakeholder betrachten das Produktinkrement (nur „Done“ gemäß Definition of Done), prüfen was sich im Umfeld geändert hat und passen das Product Backlog gemeinschaftlich an. Das Review ist ein Arbeits- und Kooperationsformat, kein Statusmeeting und keine formale Abnahme.
Zeitbox, Beteiligte, Output
- Zeitbox: bis zu 4 Stunden bei einem einmonatigen Sprint; kürzer bei kürzeren Sprints.
- Teilnehmende: gesamtes Scrum Team (Product Owner, Scrum Master, Developers) sowie relevante Stakeholder (Kunden, Business Owner, Compliance, Support, Vertrieb, ggf. Operations).
- Resultat: ein angepasstes Product Backlog (inkl. neu gewonnener Ideen, geänderter Prioritäten und realistischer Prognosen) und – wo sinnvoll – erste Hypothesen für künftige Sprint Goals.
Offizieller Fokus (Scrum Guide-konform)
- Increment inspizieren: Nur vollständig „Done“ (Definition of Done) – idealerweise als Live-Demonstration.
- Sprint Goal reflektieren: Was ist erreicht, was nicht, und warum?
- Umfeldänderungen betrachten: Markt-/Kundenfeedback, regulatorische Änderungen, technische Erkenntnisse, Risiken.
- Backlog gemeinsam anpassen: Neue Items, geänderte Prioritäten, aktualisierte Prognosen in Richtung Product Goal.
- Kooperatives Arbeiten: Review ist ein Workshop mit Dialog, nicht eine Folien-Präsentation.
Tiefgang für die Praxis: Agenda-Bausteine für Expert:innen
- Kontext & Ziel: Kurz den Product-Goal-Pfad und das Sprint Goal in Erinnerung rufen; Bezug zu Strategie/OKRs herstellen.
- Increment-Walkthrough: Nutzerfluss statt Featureliste zeigen (z. B. „vom Onboarding bis zum ersten Aha-Moment“).
- Outcome-Nachweise: Relevante Produkt-Metriken (z. B. Aktivierungsrate, Funnel-Drop-offs, Time-to-Value), Telemetrie, User-Feedback, Auszüge aus Research/Support-Tickets.
- Risiken & Entscheidungen: Was hat sich verfestigt, was bleibt hypothesenhaft? Welche Entscheidungen sind nötig (Go/No-Go, Experimente, Guardrails)?
- Backlog-Adaption live: Neue/angepasste PBIs erfassen, Hypothesen und Akzeptanzkriterien grob skizzieren, Annahmen transparent machen.
- Forecasting (leichtgewichtig): Zeitliche Erwartungen ohne Zusagen – basierend auf bisherigen Durchsätzen und bekannten Abhängigkeiten.
Skalierung: Mehrere Teams, ein Produkt
Wenn mehrere Scrum Teams am selben Produkt arbeiten, präsentieren sie ein integriertes Increment. Praktische Muster:
- Gemeinsamer Review-Slot mit Segmenten je Teamdomäne, aber durchgängiger Nutzerfluss.
- Technische Enabler sichtbar machen (Architektur-Runway, Plattform-Capabilities), sofern sie Kundennutzen im nächsten Sprint ermöglichen.
- Stakeholder-Routing: Zielgruppen-gerechte Sequenzen (z. B. zuerst Business Impact, anschließend Technik-Deep-Dive).
- Artefakt-Klarheit: Ein Product Backlog, ein Product Goal – keine konkurrierenden Backlogs für dasselbe Produkt.
Good Practices (bewährt, aber nicht Teil des Scrum Guides)
- „No Slide-Deck“-Regel: Live-System, Staging oder Click-Prototyp – echte Nutzung statt Folien.
- Outcome vor Output: Jede Demo beantwortet „Welche Wirkung erzeugt dieses Ergebnis?“ statt „Welche Tickets sind zu?“
- Review Canvas: Einseitige Struktur mit Feldern für Ziel, Key Insights, Metriken, Top-Risiken, Backlog-Änderungen, nächste Hypothesen.
- Nutzer*innen einladen: Repräsentative Kund:innen oder interne Proxy-Rollen (Support, Sales Engineering) aktiv einbeziehen.
- Compliance/Operations early: Regulatorik, Datenschutz, Security, Ops früh im Review andocken, um spätere Reibung zu vermeiden.
- Remote-Routinen: Kamera-on für Presenter, kurze Slots, technische Generalprobe, Backlog-Änderungen in Echtzeit sichtbar.
Typische Fehlmuster – und Gegenmaßnahmen
- Abnahme-Ritual statt Lernraum: Wenn Reviews zu Gate-Meetings verkommen, klare Trennung: Abnahmen (falls organisatorisch nötig) separat, Review für Lernen und Richtung.
- Folien-Schau statt Produkt: Demoziel definieren, Live-Pfad pro Persona vorbereiten, Telemetrie/Feedback integrieren.
- Nur Output, kein Outcome: Vorab 1–2 Wirkungsmetriken je Objective vereinbaren; Review an diesen messen.
- Stakeholder als Zuschauer: Timeboxed Q&A, Co-Priorisierung am Board, explizite Entscheidungsfragen vorbereiten.
- Backlog-Änderung offline: Änderungen im Review durchführen – Transparenz erzeugt Commitment.
Abgrenzung zu anderen Events
- Sprint Review ≠ Sprint Retrospektive: Review fokussiert Produkt & Richtung mit Stakeholdern; Retrospektive fokussiert Zusammenarbeit & Prozess im Scrum Team.
- Review ≠ Statusmeeting: Es geht nicht um Reporting, sondern um kollaboratives Entscheiden über nächste Schritte.
- Review ≠ Demo-Showcase: Demo ist Mittel zum Zweck – die Backlog-Adaption ist der eigentliche Outcome.
Metriken, die im Review Sinn machen
- Produkt-/Outcome-Metriken: Aktivierung, Conversion, Retention, NPS-Treiber, Erfolgskriterien aus Discovery-Hypothesen.
- Qualitäts-Signale: Fehlerraten, Wiedereröffnungsquoten, Time-to-Restore, Accessibility-Findings.
- Flow-Signale (sparsam): Cycle Time, WIP-Spitzen, Engpässe – primär zur Einordnung des Liefervermögens, nicht als Selbstzweck.
- Risikomarker: Tech-Schulden-Hotspots, Sicherheits-Findings, regulatorische Deadlines.
Rolle der Beteiligten – präzise Abgrenzung
- Developers: Demonstrieren nur Done. Beantworten Fragen zu Umsetzung, Qualität, Risiken.
- Product Owner: Kuratiert Agenda, bindet Stakeholder ein, stellt Backlog-Status, Product-Goal-Pfad und Forecasts dar, führt die Backlog-Anpassung.
- Scrum Master: Sichert Format, Timebox, Beteiligung, psychologische Sicherheit; schützt das Review vor Status-/Abnahme-Drift; fördert wirkungsvolle Moderation.
- Stakeholder: Bringen Markt-, Kunden- und Compliance-Perspektiven ein; treffen gemeinsam mit dem PO informierte Richtungsentscheidungen.
CALADE Perspektive
In vielen Unternehmen ist das Review entweder zu eng (reine Demo) oder zu breit (Status-Show). Wir unterstützen Teams dabei, das Review als strategischen Entscheidungsraum zu etablieren: klare Produktstory, Outcome-Belege, fokussierte Beteiligung und sichtbare Backlog-Adaption in Echtzeit. Unsere Coaches befähigen Product Owner und Scrum Master in Facilitation auf Expertenniveau, Stakeholder-Orchestrierung und dem Einsatz passender Metriken. So wird das Sprint Review zum Taktgeber für Richtung und Wirkung.
Verwandte Begriffe
- Sprint
- Sprint Retrospektive
- Product Owner
- Definition of Done
- Product Goal
← zurück zur Übersicht