Sprint Review
Eine Scrum-Zeremonie, die am Ende jedes Sprints stattfindet, bei der das Team das funktionierende Inkrement den Stakeholdern präsentiert und Feedback sammelt. Im Gegensatz zu einem Statusbericht ist das Sprint Review eine kollaborative Arbeitssitzung — die Stakeholder prüfen, was gebaut wurde, stellen Fragen und beeinflussen das Produkt-Backlog basierend auf dem, was sie sehen.
Moderationsablauf
- 1
Eröffne, indem du das Sprint-Ziel und die Zusagen des Teams noch einmal nennst, und sage dann klar, was 'Done' ist und was nicht — und warum. Rahme die Session: 'Das ist eine Arbeitssession, keine Präsentation — unterbrecht uns, stellt Fragen und sagt uns, was ihr ändern würdet.'
5 Min. - 2
Lass die Entwickler:innen das Inkrement demonstrieren — jede Person zeigt die Arbeit, die sie gebaut hat, im echten Produkt und entlang einer realistischen User Journey statt einer Feature-Checkliste. Keine Folien, keine Mock-ups, nichts, das nicht 'Done' ist.
20 Min. - 3
Gib die Steuerung ab: Lass Stakeholder das Produkt selbst ausprobieren, wo es praktikabel ist, und halte jede Frage, Reaktion und Anregung sichtbar auf einem Board fest, sobald sie auftaucht. Sprich die stillen Teilnehmenden direkt an: 'Wofür würdest du das nutzen? Was fehlt dir dafür?'
10 Min. - 4
Wechsle zum Backlog-Gespräch, geführt vom Product Owner: 'Was sollten wir angesichts dessen, was ihr gerade gesehen habt, als Nächstes priorisieren?' Geh die Spitze des Backlogs durch und passe sie offen an — Items, die vor den Augen der Stakeholder nach oben oder unten wandern, sind das Review, wie es gedacht ist.
10 Min. - 5
Zoome kurz heraus: Teile alles, was sich seit dem letzten Review an Zeitplan, Budget oder Markt verändert hat, und gib eine realistische Prognose, worauf sich der nächste Sprint voraussichtlich konzentriert.
5 Min. - 6
Schließe ab, indem du das festgehaltene Feedback noch einmal vorliest, bestätigst, welche Punkte ins Produkt-Backlog wandern und welche bewusst geparkt werden, und dich bei den Stakeholdern konkret für den Input bedankst, der etwas verändert hat.
5 Min.
Tipps
Das Sprint Review ist kein formelles Abnahme-Meeting — es ist ein Gespräch. Halte es kollaborativ.
Zeige nur funktionierende Software. Unvollständige Funktionen zu demonstrieren, untergräbt das Vertrauen.
Lade echte Nutzer ein, nicht nur interne Stakeholder, wann immer möglich — ihr Feedback ist wertvoller.
Halte die Zeit strikt ein: 1 Stunde pro Woche Sprintlänge (maximal 4 Stunden für einen einmonatigen Sprint).
Typische Stolperfallen
Das Review in einstudierte Foliensätze verwandeln — eine polierte Präsentation lädt zu Applaus statt zu Inspektion ein, und das Team lernt nichts mehr, was es nicht schon wusste
Scrum Master oder Product Owner alles demonstrieren lassen, während die Entwickler:innen stumm dabeisitzen — die Menschen, die die Arbeit gebaut haben, beantworten Fragen besser und wachsen am direkten Kontakt
Nach der Demo aufhören und das Backlog-Gespräch überspringen — Inspektion ohne Anpassung ist nur ein halbes Review, und die Feedback-Schleife, für die das Event existiert, schließt sich nie
Feedback nirgendwo festhalten — Stakeholder merken innerhalb von zwei oder drei Sprints, dass ihre Kommentare verschwinden, und kommen dann nicht mehr
Variationen
Remote Sprint Review: Nutze Bildschirmfreigabe + ein Miro-Board, auf dem Stakeholder während der Demo Haftnotizen ablegen. Asynchrone Variante: Nimm eine Loom-Demo auf, sammle schriftliches Feedback über ein Formular und halte dann eine 30-minütige Diskussionssitzung ab.
Einsatzbereiche
Wann einsetzen
Jeden Sprint gemeinsam mit den Stakeholdern abschließen, deren Prioritäten das Produkt-Backlog tatsächlich prägen — das Review ist der fest eingebaute Moment des Teams, das Inkrement gemeinsam zu inspizieren
Stakeholder werden beim Release immer wieder überrascht — regelmäßige Reviews funktionierender Software ersetzen Big-Bang-Enthüllungen durch kleine, korrigierbare Kurskorrekturen
Backlog-Prioritäten werden aus Meinung und Hierarchie heraus verhandelt — Feedback, das entsteht, während Stakeholder sich durch ein echtes Inkrement klicken, lässt sich schwerer abtun als Spekulation im Meetingraum
Ein Team ertrinkt in Statusbericht-Meetings — ein gut geführtes Review mit einer Live-Produktdemo ersetzt Foliensätze und gibt Stakeholdern etwas, worauf sie tatsächlich reagieren können
Wann nicht einsetzen
In diesem Sprint hat nichts den Status 'Done' erreicht — halbfertige Arbeit zu demonstrieren untergräbt Vertrauen; führe ein kurzes, ehrliches Gespräch darüber, was passiert ist, und nimm die tiefere Analyse mit in die Retrospektive
Als Abnahme-Gate, bei dem Stakeholder Arbeit formal freigeben — die Abnahme gegen die Definition of Done passiert während des Sprints; wird das Review zur formalen Genehmigungszeremonie, probt das Team Theater, statt zur Inspektion einzuladen
Für die interne Prozessdiskussion des Teams — wie sich der Sprint angefühlt hat, was an der Arbeitsweise zu verbessern ist — dieses Gespräch gehört in die Sprint-Retrospektive, ohne Stakeholder im Raum
Wenn niemand im Raum das Backlog beeinflussen kann — ein Review für passive Zuschauer ist eine Demo, keine Inspektion; nimm stattdessen ein kurzes Walkthrough-Video auf und reserviere die Live-Session für Menschen, deren Feedback verändert, was gebaut wird
Ähnliche Methoden
Weiterführende Artikel
Häufig gestellte Fragen
Wie lange sollte ein Sprint Review dauern?▾
Eine nützliche Faustregel ist eine Stunde Review pro Sprintwoche; der Scrum Guide deckelt es bei vier Stunden für einen einmonatigen Sprint. Für die ein- und zweiwöchigen Sprints der meisten Teams sind 30–60 Minuten realistisch: grob die Hälfte für die Demonstration und die Hälfte für Feedback und Backlog-Gespräch.
Wer sollte am Sprint Review teilnehmen?▾
Das gesamte Scrum-Team plus die Stakeholder, die auf das Gesehene reagieren können — Sponsor:innen, Schlüsselnutzer:innen und alle, deren Feedback das Backlog prägen soll. Es funktioniert von einer Handvoll Personen bis zu etwa 30; lade wann immer möglich echte Nutzer:innen ein, deren Reaktionen mehr wert sind als eine weitere Runde internen Nickens.
Was ist der Unterschied zwischen Sprint Review und Sprint-Retrospektive?▾
Das Review inspiziert das Produkt gemeinsam mit den Stakeholdern — was gebaut wurde, welches Feedback es bekommt, wie das Backlog als Nächstes aussehen sollte. Die Retrospektive inspiziert den Prozess innerhalb des Teams — wie der Sprint lief und was an der Arbeitsweise zu verbessern ist. Es sind getrennte Events mit unterschiedlichem Publikum, und sie zu verschmelzen tötet meist die Offenheit, die beide brauchen.
Wie führt man ein Sprint Review remote durch?▾
Teile das laufende Produkt per Bildschirmfreigabe — keine Folien — und kombiniere es mit einem geteilten Board, auf dem Stakeholder ihr Feedback als Haftnotizen ablegen, während sie zuschauen; so wird jeder Kommentar festgehalten, ohne den Fluss zu unterbrechen. Für verteilte Stakeholder funktioniert auch eine asynchrone Variante: Nimm ein kurzes Demo-Video auf, sammle schriftliches Feedback über ein Formular und halte dann eine 30-minütige Live-Diskussion zu den Rückmeldungen.
Was sollte man für ein Sprint Review vorbereiten?▾
Bestätige, welche Items die Definition of Done tatsächlich erfüllen, kläre, wer was demonstriert, und geh den Demo-Pfad einmal in einer stabilen Umgebung durch, damit die Session nicht mit Debugging vergeht. Darüber hinaus sollte die Vorbereitung leicht bleiben — ein überproduziertes Review ist ein Warnsignal, dass aus Inspektion Performance geworden ist.
Plane deinen nächsten Workshop mit KI
Workshop Weaver kombiniert Methoden wie Sprint Review zu einer vollständigen, zeitlich geplanten Agenda. In Minuten.
Kostenlos testenMethod descriptions on Workshop Weaver are original content written by our team, based on established facilitation practices. This method was inspired by work from Scrum Guide.