Sprint-Review: Was es ist & wie man es 2026 durchführt
Sprint Review Meetings können herausfordernd sein; in diesem Beitrag teile ich, wie man sie einfacher gestalten kann. Wenn dein Team hart gearbeitet hat und seine Fortschritte präsentiert, in der Hoffnung, dass die Aufgaben aus dem Sprint Backlog abgenommen werden, möchtest du, dass diese lieferbaren Inkremente genehmigt werden. Lass uns anschauen, wie du das erreichst.
Was ist ein Sprint Review Meeting?
Ein Sprint Review Meeting ist ein Zusammentreffen des Produkt- (oder Projekt-)Teams und des Product Owners am Ende eines Sprints, um die aus dem Sprint Backlog erledigten Arbeiten zu überprüfen.
Im Sprint Review Meeting präsentiert und demonstriert das Team die Aufgaben aus dem Sprint Backlog, die sie für lieferbar halten. Der Product Owner nimmt anschließend Features an oder lehnt sie ab – je nachdem, ob sie die Nutzerbedürfnisse, die Akzeptanzkriterien, die Definition of Done (DoD) und seine Erwartungen erfüllen. Danach bespricht er mit dem Team das weitere Vorgehen.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Für Sprint Reviews werden in der Regel Scrum-Software oder Agile-Projektmanagement-Software genutzt, um den Fortschritt zu demonstrieren. Daran nehmen meist das Scrum-Team, der Scrum Master, der Product Owner und gegebenenfalls weitere Stakeholder teil. Es ist eines der drei Scrum-Zeremonien bzw. 'Events', die das agile Scrum-Framework kennzeichnen. Sie heißen Zeremonien, sind letztlich aber einfach Meetings!
Warum ein Sprint Review durchführen?
Das Ziel eines Sprint Reviews ist die Zusammenarbeit in Echtzeit zwischen dem Scrum-Team, Product Owner und Stakeholdern. Es dient als Demo des Projektfortschritts und führt zur Freigabe von Backlog-Elementen zum Versand.
7 Vorteile eines Sprint Review Meetings
- Feedback und Zusammenarbeit: Sprint Reviews bieten eine Plattform für Stakeholder-Feedback und ermöglichen eine frühe Erkennung und Behebung von Problemen. Das trägt dazu bei, ein qualitativ hochwertiges Produkt zu entwickeln, das den Nutzerbedürfnissen und Erwartungen entspricht.
- Erhöhte Transparenz: Sprint Reviews verbessern die Transparenz des Entwicklungsprozesses. Durch die Präsentation der geleisteten Arbeit, Velocity und die Diskussion der nächsten Schritte erhalten Stakeholder einen klaren Überblick über Projektfortschritt, Herausforderungen und die Kapazität des Teams.
- Team-Alignment und Fokus: Die Überprüfung des Sprint-Fortschritts anhand der Sprint-Ziele hilft, das Team ausgerichtet und fokussiert zu halten. Sie schafft Klarheit über Erwartungen und Prioritäten für zukünftige Sprints.
- Stakeholder-Engagement und Zufriedenheit: Der regelmäßige Austausch mit Stakeholdern in diesen Meetings steigert deren Engagement und Zufriedenheit. Es vermittelt ihnen ein Gefühl von Mitverantwortung und aktiver Beteiligung am Entwicklungsprozess.
- Anpassungsfähigkeit und Flexibilität: Sprint Reviews ermöglichen es Teams, Pläne basierend auf Feedback und sich ändernden Anforderungen anzupassen. Diese Flexibilität ist entscheidend für den Erfolg eines agilen Vorgehens bei unsicherem Umfang.
- Motivation und Anerkennung: Sprint Reviews sind eine Plattform, auf der das Scrum-Team seine Arbeit präsentieren kann, was die Moral steigert. Die Anerkennung von Anstrengungen und Erfolgen vor Stakeholdern wirkt hoch motivierend.
- Lern- und Verbesserungsmöglichkeiten: Sprint Reviews bieten dem Team die Gelegenheit, über eigene Prozesse und Vorgehen zu reflektieren und sowohl aus Erfolgen als auch aus Herausforderungen zu lernen. Dieses kontinuierliche Lernen fördert eine Kultur der ständigen Verbesserung.
Was passiert während eines Sprint Reviews?
Während des Sprint Reviews gibt das Projektteam einen Überblick über die im Sprint erzielten Fortschritte sowie über Blocker oder Hindernisse, die die Fertigstellung bestimmter Aufgaben oder Deliverables verhindert haben.
Du kannst darauf eingehen, wie und warum Verzögerungen oder Blocker entstanden sind, solltest das Team jedoch davon abbringen, Schuldzuweisungen vorzunehmen oder detaillierte Diskussionen über Kommunikations- und Kollaborationsprobleme zu führen (das wird im Sprint Retrospective behandelt; siehe nächsten Abschnitt).
Fokussiere dich mit dem Team auf konkrete Schritte, um Blockaden zu beseitigen, wieder auf Kurs zu kommen und realistische Deadlines für verbleibende oder verzögerte Aufgaben festzulegen.
Abschließend demonstriert das Projektteam die während des Sprints fertiggestellten Kernergebnisse oder Produktfeatures und die Stakeholder können Feedback geben.
Verhindere, dass aus dem Sprint Review ein Pressebriefing wird, indem du auf statische Präsentationen verzichtest – dieses Format ist selten produktiver als eine E-Mail.
Sprint Review vs. Sprint Retrospective
Ein Sprint Review sollte nicht mit einer Sprint Retrospective verwechselt werden (obwohl man sie leicht durcheinanderbringen kann!). Beide sind wichtige Bestandteile des Scrum-Prozesses und sie sind die beiden letzten Schritte im Zyklus, aber die Durchführung unterscheidet sich.
Ein Sprint Review konzentriert sich auf das Produkt, während das Retrospective Meeting sich auf den Prozess selbst fokussiert.
Stell dir vor, du stehst kurz vor dem Ende des Sprints und das Sprint Backlog ist so gut wie abgearbeitet.
Sie planen ein Sprint-Review, um den Fortschritt Ihres Scrum-Teams hinsichtlich der Lieferung zu überprüfen und alle verbleibenden Hindernisse aus dem Weg zu räumen.
Nehmen wir zum Beispiel an, dieser Sprint bestand darin, 10.000 Codezeilen für die App zu produzieren, an der das Team arbeitet. Das Sprint-Review-Meeting ist der Ort, um sicherzustellen, dass der Code läuft und validiert ist und Sie bereit sind, mit ihm live zu gehen.
Im Gegensatz dazu betrachtet die Retrospektive den Prozess, den Sie im letzten Sprint verfolgt haben, mit dem Ziel, die Abläufe im nächsten Sprint zu verbessern.
Während der Retrospektive sammeln Sie Feedback zu den Erfahrungen der Teammitglieder bei der Integration ins Team, der Kommunikation über Codeänderungen oder was sonst den Prozess beeinflusst hat.
Die Retrospektive soll eine Art Nachbesprechung sein, bei der alle lernen können, besser zusammenzuarbeiten, unabhängig vom Produkt.
Fragen Sie die Teammitglieder, wie sie sich fühlen und ob sie Vorschläge für die nächste Arbeitsrunde an Ihrem Projekt haben:
- Was möchten sie im nächsten Sprint sehen?
- Hatten sie das Gefühl, unter Druck zu arbeiten?
- Hatten sie zu viel Zeit zur Verfügung?
Es ist immer noch verlockend, die Grenzen zwischen einem Sprint-Review und einer Retrospektive zu verwischen. Wenn Sie bereits ein Sprint-Review vorbereitet haben, sind ohnehin alle versammelt, warum also nicht beides auf einmal machen?
Der Scrum Guide rät davon ab, und wenn Sie alles in einer einzigen Sitzung durchführen müssen, sollten Sie die beiden Phasen Ihres Meetings klar voneinander abgrenzen, um ein Vermischen zu vermeiden.
Hier ist eine kurze Übersicht, welche Themen in welche Meetings gehören und wann Sie das Scrum-Team wieder auf Kurs bringen sollten, falls eine Retrospektive während eines Sprint-Reviews zu entgleisen droht.
| Sprint-Review oder Retrospektive | Was ist enthalten | Was ist nicht enthalten |
|---|---|---|
| Sprint-Review | Ob die Product Backlog Items abgeschlossen sind Warum die Product Backlog Items nicht abgeschlossen sind Neue Funktionen und Eigenschaften des Produkts Liefertermin des Produkts oder ein realistischer Release-Plan | Wie schwierig es war, die Frist einzuhalten Wie schlecht sich die Leute fühlen, weil die Frist verpasst wurde Wie es Julies Schuld ist, dass wir die Frist nicht eingehalten haben Dass Fristen nur Zahlen sind und alle entspannter sein sollten |
| Sprint-Retrospektive | Wie die Kommunikation im Team gelaufen ist Vorschläge zur Optimierung des Workflows und der Teamprozesse Möglichkeiten, Entwicklungsteams agiler zu gestalten Erfolgskriterien und methodisches Vorgehen zur Entwicklung von Standards für realistische Meilensteine | Probleme mit dem Produkt selbst Eigenschaften des aktuellen Produkts Pläne für technische Einzelheiten oder eine Vorlage für spezifische Ziele |
Tipps zur Vorbereitung des Sprint-Reviews
Wenn Sie ein System zum Sammeln von Produktfeedback implementieren und daran festhalten, können Sie effektiv eine Maschine für kontinuierliche Verbesserung und Iteration aufbauen.
Wie fangen Sie nun an, ein Sprint-Review durchzuführen? Hier einige Tipps, die Sie beachten sollten:
- Stellen Sie sicher, dass jedes Teammitglied weiß, wann und wo das Review stattfindet und welche Rolle im Review es einnimmt. Je mehr Zeit Sie zur Vorbereitung geben, desto produktiver ist das Team, wenn es über seinen Fortschritt berichtet.
- Fokussieren Sie sich auf das Produkt und darauf, was gebaut wurde. Machen Sie das Meeting zu einer interaktiven Erfahrung, bei der der Product Owner und die Stakeholder das Produkt sehen und damit interagieren können. Dieser Ansatz hilft, wertvolles Feedback zu erhalten und fördert die Einbindung der Stakeholder.
- Seien Sie gründlich vorbereitet und stellen Sie sicher, dass alle Arbeitsergebnisse abgeschlossen und präsentationsbereit sind. Überlegen Sie sich vorab, wie Sie demonstrieren, dass die Backlog-Items die User Story und die Definition of Done erfüllen und wirklich auslieferungsbereit sind.
- Bereiten Sie Demos vor, indem Sie im Voraus Themen sammeln und sowohl die virtuellen als auch die physischen Räume entsprechend einrichten.
- Erstellen Sie eine einfache Notizenvorlage, um die Ergebnisse des Meetings zu dokumentieren. Agile-Methoden betonen eine begrenzte Dokumentation, also machen Sie sich keine Sorgen um zu viele Details. Es geht lediglich darum, Ihre Maßnahmen im Blick zu behalten.
Wie man ein Sprint-Review-Meeting durchführt
Obwohl Sie Sprint-Reviews nach Belieben strukturieren können, gibt es bessere und weniger geeignete Ansätze. Hier einige Schritte zur Durchführung von Sprint-Reviews, die sich für die meisten, die der Scrum-Methode folgen, bewährt haben:
- Überblick über Fortschritte und Rückschläge
- Nachbesprechung zu Erfolgen und Misserfolgen
- Entwicklung eines Plans zur Beseitigung von Hindernissen
- Feature-Demonstration
1. Fortschrittsüberblick
Gehen Sie reihum und lassen Sie alle berichten, wie es mit dem Produkt vorangeht. Haben sie ihre Sprint-Ziele erreicht? Erfüllen die Ergebnisse die Benutzeranforderungen, die User Story und die Definition of Done?
Falls nicht, wie nah sind sie derzeit dran, und wann werden sie fertig? Lassen Sie die Diskussion nicht in Erklärungen zum Grund für eine Verzögerung abdriften.
Konzentrieren Sie sich auf ein unkompliziertes Berichten über Fortschritte (oder deren Fehlen). Warum-Diskussionen finden später statt, nachdem alle ihre Berichte abgegeben haben und Sie wissen, wie weit die einzelnen Projektbereiche fortgeschritten sind.
2. Nachbesprechung
Hier können die Gründe für Fehlentwicklungen besprochen werden. Gehen Sie diesen Teil der Agenda an, nachdem jedes Teammitglied zu Wort gekommen ist und Sie wissen, wie der Stand in allen Phasen des Rollouts ist.
Nehmen Sie die Nachbesprechung zum Anlass, zunächst die positiven Ergebnisse zu beleuchten. Notieren Sie die Projektziele, die gut gelaufen sind, und versuchen Sie einzuschätzen, wie nah die Arbeiten vor der Abgabe an der Deadline abgeschlossen waren. So bekommen Sie eine Vorstellung davon, ob das Tempo im kommenden Sprint erhöht werden kann.
Betrachten Sie dann etwaige Defizite und fragen Sie nach, wie es zu der Verzögerung kam und wann diese behoben sein wird. Gehen Sie dabei nicht zu hart mit dem Team ins Gericht. Wenn alle ihre Ziele schon drei Tage vor Ende eines fünftägigen Sprints erreichen, setzen Sie vermutlich die Ziele nicht hoch genug an.
3. Beseitigung von Hindernissen
Versuchen Sie vorherzusehen, auf welche Hindernisse Sie in den kommenden Sprints stoßen könnten. Dazu gehören etwa ein knappes Budget, der Bedarf an spezifischer Expertise von außerhalb Ihres aktuellen Teams, regulatorische Fragen oder Berichtspflichten, oder Änderungen der Marktbedingungen, die die Nachfrage nach dem Produkt beeinflussen könnten.
Ziel dieser Phase ist es, solche Hindernisse frühzeitig zu erkennen und bereits jetzt zu planen, wie Sie diese bewältigen, bevor sie in den nächsten Tagen einen Engpass verursachen. Nutzen Sie diese Informationen, um den Product Backlog gegebenenfalls zu aktualisieren.
4. Produkt-Demonstration
In dieser Phase ergänzen Sie den Produktüberblick durch die Präsentation der wichtigsten Neuerungen, die im letzten Sprint ausgeliefert wurden. Das ist vor allem eine Gelegenheit, die Erfolge des Teams ins Rampenlicht zu rücken und die Motivation zu stärken.
Agenda für das Sprint Review Meeting
Hier ein Beispiel für eine Meeting-Agenda für Ihr Sprint Review (mit empfohlenen Zeitlimits):
1. Einführung (5 Minuten)
- Kurze Begrüßung und Vorstellung
- Zweck und Ziele des Meetings kurz darlegen
2. Rückblick auf die Sprint-Ziele (10 Minuten)
- Die zu Beginn des Sprints gesetzten Ziele rekapitulieren
- Die Schwerpunkte des Sprints hervorheben
3. Produkt-Demonstration (20-30 Minuten)
- Vorstellung der im Sprint erledigten Arbeiten
- Präsentation neuer Funktionen, Verbesserungen und Fehlerbehebungen
- Kurzfragen im Anschluss an jede Demonstration zulassen
4. Überprüfung des Product Backlogs (10 Minuten)
- Aktuellen Stand des Product Backlogs überprüfen
- Diskussion über neu hinzugefügte, entfernte oder umpriorisierte Elemente während des Sprints
5. Feedback-Runde (15-20 Minuten)
- Feedback von Stakeholdern und Teammitgliedern einholen
- Besprechen, was gut gelaufen ist und was verbessert werden könnte
- Offene und ehrliche Diskussionen fördern
6. Überprüfung von Kennzahlen und Performance (10 Minuten)
- Schlüsselkennzahlen (KPIs), Velocity und weitere relevante Leistungsdaten besprechen
- Geplanten vs. tatsächlichen Fortschritt vergleichen
7. Ausblick (10 Minuten)
- Erste Überlegungen für den nächsten Sprint skizzieren
- Mögliche Backlog Items identifizieren
- Erläutern, welche Anpassungen aufgrund des Feedbacks und der Überprüfung vorgenommen werden könnten
8. Abschluss (5 Minuten)
- Fassen Sie die wichtigsten Erkenntnisse und Entscheidungen zusammen
- Bestätigen Sie das Datum und die Ziele für das nächste Sprint-Planungsmeeting
- Danken Sie allen für ihre Teilnahme und ihren Beitrag
9. Offene Runde (Optional, 5–10 Minuten)
- Geben Sie Raum für abschließende Fragen oder Kommentare
- Sprechen Sie sonstige Themen oder Ankündigungen an
FAQs zu Sprint-Reviews
Zur Übersicht haben wir Antworten auf einige der am häufigsten gestellten Fragen zu Sprint-Reviews zusammengestellt.
Wer nimmt an der Sprint-Review teil?
Zu den wichtigsten Teilnehmern einer Sprint-Review zählen der Scrum Master, Product Owner und Product Manager. Je nach Projekt kann es hilfreich sein, weitere relevante Stakeholder einzuladen (achten Sie jedoch darauf, dass die Gruppe nicht so groß wird, dass das Meeting schwer zu steuern ist.)
Wie lange sollte die Sprint-Review dauern?
Der Scrum Guide empfiehlt, Sprint-Review-Meetings bei zweiwöchigen Sprints auf maximal 2 Stunden zu begrenzen (eine Stunde für jede Woche, die Ihr Sprint dauert.)
Meiner Meinung nach sind 2 Stunden sehr lang für ein Meeting. Ich empfehle, die Sprint-Review auf 45 Minuten zu verkürzen, davon 15 Minuten am Ende für Produkt-Demos. Bei größeren Teams können Sie wöchentlich abwechseln, wer eine Demo präsentiert.
Wie oft finden Sprint-Reviews statt?
Sprint-Reviews finden am Ende jedes Sprints statt, sie sollten also im gleichen Rhythmus wie die Sprintzyklen Ihres Teams abgehalten werden. Arbeiten Sie beispielsweise in zweiwöchigen Sprints, gibt es alle zwei Wochen eine Sprint-Review.
Unsere Statusreport-Vorlage für Projekte enthält eine Struktur für wöchentliche oder zweiwöchentliche Berichte, die Sie zu jeder Sprint-Review mitbringen können.
Was passiert nach der Sprint-Review?
Nach der Sprint-Review wird das Product Backlog im Projektmanagement-Tool Ihres Teams auf Basis der besprochenen Hindernisse aktualisiert und diese Informationen für die Vorbereitung auf das Sprint-Planungsmeeting genutzt.
Für die Planung des nächsten Sprints (oder eines gesamten Projekts) empfiehlt es sich, das Backlog in einem Projektplanungstool oder einer ähnlichen Software zu organisieren.
Was ist ein Sprint?
Ein Sprint ist eine kurze, zeitlich abgesteckte Phase, in der Ihr Team auf festgelegte Ziele hinarbeitet, mit dem Ziel, am Ende eine potenziell auslieferbare Produkt-Inkrement bereit zu haben.
Wie geht es weiter?
Haben Sie eigene Tipps und Tricks für die Durchführung von Sprint-Reviews? Teilen Sie Ihre Erfahrungen und diskutieren Sie mit Hunderten anderen Digital Project Managern in unserem Slack-Channel – mit der DPM-Mitgliedschaft!
