Sprint Review

English
Sprint Review

Das Sprint Review ist in Scrum ein verpflichtendes Meeting zum Informationsaustausch am Ende eines jeden Sprints. Sein Ziel ist es, die Ergebnisse des abgelaufenen Sprints vorzustellen und diesbezüglich Feedback von den Stakeholdern einzusammeln. Der auch als "Demo" bezeichnete Sprint Review dient zur Überprüfung der zuletzt erstellten Produktinkremente und – wenn nötig – zur Anpassung des Product Backlogs. Die Sprintziele werden hierfür mit den erzielten Ergebnissen abgeglichen, indem der Product Owner jedes Backlog-Item hinsichtlich der Definition of Done verifiziert.

Sprint Review
Download PDFDownload PDF
Download PDF (English)Download PDF (English)

Sprint Review

English
Sprint Review

Das Sprint Review ist in Scrum ein verpflichtendes Meeting zum Informationsaustausch am Ende eines jeden Sprints. Sein Ziel ist es, die Ergebnisse des abgelaufenen Sprints vorzustellen und diesbezüglich Feedback von den Stakeholdern einzusammeln. Der auch als "Demo" bezeichnete Sprint Review dient zur Überprüfung der zuletzt erstellten Produktinkremente und – wenn nötig – zur Anpassung des Product Backlogs. Die Sprintziele werden hierfür mit den erzielten Ergebnissen abgeglichen, indem der Product Owner jedes Backlog-Item hinsichtlich der Definition of Done verifiziert.

Sprint Review
Wir empfehlen zum Thema Scrum
26.06.2024
795,00,-
So gelingen Veränderungen unter hoher Auslastung

In diesem Workshop betrachten wir verschiedene Wege, wie Unternehmen Veränderungen unter Vollauslastung des Systems erfolgreich einleiten und umsetzen können. Mehr Infos

Einsatzmöglichkeiten

  • Der Sprint Review ist ein fester Bestandteil des agilen Frameworks Scrum und wird immer am Ende eines Sprints durchgeführt.
  • Review-Meeting in anderen Vorgehensmodellen: Review Meetings, die analog zur Methode des Sprint Reviews aufgebaut sind eignen sich auch außerhalb von agilen Vorgehensmodellen zum Austausch zwischen Umsetzungsteams und Kunden.

 

Ergebnisse

  • Dediziertes Feedback an das Entwicklerteam zum Produktinkrement
  • ggf. aktualisiertes Product Backlog
  • ggf. angepasster Release Plan
  • ggf. aktualisierte Definition of Done

Vorteile

Das Entwicklungsteam erhält die Möglichkeit, die geleistete Arbeit direkt den relevanten Stakeholdern und dem Product Owner vorzustellen und dadurch unmittelbares Feedback zu erhalten.
Es erfolgt ein direkter Austausch zwischen Entwicklungsteam, Management sowie den Anwendern bzw. Kunden. Dies ist auch im Sinne eines aktiven Risikomanagements.
Änderungswünsche können direkt adressiert und eingeplant werden, Ideen für weitere Funktionalitäten werden gemeinsam eruiert.
Das Meeting bedarf keiner großen Vorbereitung, da keine Präsentation erstellt werden muss, sondern lediglich das erstellte Produkt präsentiert wird.
Die Motivation, das Sprintziel zu erreichen, steigt für das Team, da nur fertige, lauffähige Produkte präsentiert werden dürfen.

Durchführung: Schritt für Schritt

Schritt 1: Scrum Master und Product Owner bereiten den Sprint Review vor

Der Scrum Master ist in erster Linie für die Vorbereitung des Sprint Reviews verantwortlich. Neben organisatorischen Punkten wie der Raumreservierung, sollte er vorab Informationen über die erstellten Produktinkremente allen Teilnehmern zur Verfügung zu stellen. Dies ermöglicht es dem Publikum, sich optimal auf den Termin vorzubereiten. Ferner sollte er mögliche Fragen des Entwicklerteams an den Product Owner bzw. die Stakeholder sammeln und zusammenstellen.

Der Product Owner ist für die "Gästeliste" zuständig, d.h. er lädt die benötigten Stakeholder ein wie z.B. das Management, Entwickler aus anderen Teams, Kunden und Anwender.

Bei einer Sprintlänge von einem Monat wird ein Sprint Review von vier Stunden vorgeschlagen. Bei kürzeren Sprints verringert sich die Dauer im entsprechenden Verhältnis.

Um zu vermeiden, dass das Sprint Review als Freigabe-Meeting missbraucht wird, sollte der Product Owner die umgesetzen Backlog Items bereits vor dem Meeting freigeben. Die Freigabe erfolgt immer durch den Product Owner gemäß der Definition of Done und nicht durch andere Stakeholder. Sollten aufgrund des Stakeholder-Feedbacks Änderungen nötig werden, sind diese über ein neues Product-Backlog-Item einzusteuern.

Aufgabengebiete

Alle Kommentare (4)

Guest

Eine von vielen Seiten, welche die falsche/veraltete Information beinhalten, dass das Team im Sprint Review auch dem Product Owner die Arbeitsergebnisse vorstellt. Ich würde dem Autor hier die Lektüre des aktuellen Scrum Guides vorschlagen.

 

Georg
Angermeier
Dr.

Hallo Herr Bauer, also im Scrum Guide 2017 steht unter "Sprint Review" auf Seite 13: "The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;" Haben Sie einen aktuelleren Scrum Guide? Oder interpretieren Sie "work it has 'Done'" nicht als Arbeitsergebnis? Oder habe ich Ihren Kommentar falsch verstanden? Beste Grüße Georg Angermeier

 

Peter
Müller

Folgende Situation: Das Development Team hat bereits nach einigen Tagen das erste Product Backlog Item umgesetzt (ist also der Meinung, es sei "fertig"). Angenommen, der Product Owner würde jetzt wirklich erst im Sprint Review das Item abnehmen. Dann hätte das Development Team keine Chance bei Nichtabnahme korrektive Maßnahmen für das Item zu ergreifen. Kurz, es wäre schlicht zu spät. Und das macht keinen Sinn. Stattdessen sollte natürlich der PO auch während des Sprints Items abnehmen, sobald das Development Team Items "fertig" hat. Nur so ist es möglich, Missverständnisse z. B. bzgl. der Akzeptanzkriterien rechtzeitig zu entdecken und zu beheben, um dann doch noch das Item wirklich "fertig" zu stellen. Der wesentliche Zweck des Sprint Reviews ist auch nicht die Abnahme durch den PO sondern das Kollaborieren mit den Stakeholdern, um über die nächsten sinnvollen Schritte nachzudenken. Hierzu wird den Stakeholdern das Inkrement zum Ausprobieren angeboten (und möglichst nicht nur demonstriert). Der Begriff "Demo" ist hier irreführend und verleitet dazu, dieses Event viel zu passiv zu gestalten. Das Sprint Review ist (erneut) ein Planungsmeeting. Es erlaubt dem PO dank des Feedbacks der Stakeholder den Product Backlog so zu gestalten, dass auch im nächsten Sprint der höchste Wert erzeugt werden kann.

 

Hallo Herr Müller, vielen Dank für Ihre ergänzenden Ausführungen! Ich bin hier in allen Punkten vollständig Ihrer Meinung. Die enge Zusammenarbeit zwischen Product Owner und Entwicklungsteam während des Sprints ist ja gerade eine der größten Stärken des agilen Arbeitens. Das ist freilich kein Widerspruch dazu, dass im Sprint Review das gesamte Ergebnis des Sprints betrachtet wird. Nicht mehr im Sinne einer detaillierten Prüfung und Abnahme - das geht ja gar nicht im engen Zeitrahmen - sondern im Sinne einer Gesamtbetrachtung. Deshalb steht ja im Text auch: "Nicht die Demonstration der Ergebnisse, sondern der offene Diskurs über den aktuellen Stand des Produkts ist der primäre Zweck des Meetings." Ich empfinde Ihren Beitrag als sehr wertvoll, da er deutlich macht, dass wir bei den Methodenbeschreibungen noch nach Wegen suchen müssen, um solche Zusammenhänge besser darzustellen.