Projektmanagement-Methode
Alle Methoden

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

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

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.
Christian Botta live erleben auf der PM Welt am 21. April 2020!

Erleben Sie den Vortrag "5+ VISUELLE QUICK-HACKS - Für eine bessere Kommunikation und Kooperation" sowie 30 weitere Speaker in 7 Streams auf der PM Welt 2020.

Das Thema der Konferenz lautet
Stark durch Kooperation! Zusammen.Arbeiten.Grenzenlos.
Die Teilnehmer erhalten in den unterschiedlichen Vorträgen, Diskussionen und Workshops konkrete Anleitungen und Tipps für ihren Projektalltag.

 

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.

Grenzen, Risiken, Nachteile

  • Die Gruppe der Teilnehmer kann unter Umständen sehr groß werden (über 40 Personen). Dies hat zur Folge, dass der zeitlich vorgegebene Rahmen von vier Stunden (s.u.) bei großen Gruppen oft nicht eingehalten werden kann.
  • Die richtige Besetzung des Sprint Reviews ist essentiell. Sollten beispielsweise das Management oder Schlüsselkunden fehlen, kann der Wert des erstellten Produkts nicht zweifelsfrei verifiziert werden.
  • Geringe Präsentationsfertigkeiten der Entwickler können zu mangelnder Akzeptanz und Verständnisproblemen bei den Zuschauern führen.
  • Mangelnde Bereitschaft des Managements zur Teilnahme an Sprint Reviews, da diese als nicht wichtig genug eingestuft werden.
  • Das Sprint Review wird als Freigabe-Meeting missbraucht.

Ergebnis

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

 

Voraussetzungen

  • Dem Sprint Review muss ein abgeschlossener Sprint vorangehen.
  • Das Scrum Team (Product Owner, Scrum Master und Entwicklungsteam) muss vollständig anwesend sein.

 

Qualifizierung

  • Der Scrum Master muss die Regeln von Scrum sowie des Sprint Review kennen und sie bei Bedarf den Teilnehmern des Sprint Review erklären können.
  • Der Product Owner sollte als Leiter des Review über Moderationskenntnisse verfügen.
  • Die das Inkrement vorstellenden Entwickler sollten grundlegende Präsentationsfähigkeiten besitzen.

 

Benötigte Informationen

  • Sprint Goal inklusive Sprint Backlog Items und zugehöriger Definition of Done. Dies entspricht den Aufgaben, die das Entwicklungsteam geplant hatte, im abgelaufenen Sprint umzusetzen.
  • Das potentiell auslieferbare Inkrement, d.h. die Software, die das Team im vorangegangenen Sprint tatsächlich umgesetzt hat.
  • Aktueller Product Backlog
  • Aktueller Release Plan

 

Benötigte Hilfsmittel

Je nach Art der Präsentation sollten Flipcharts, Whiteboards oder Beamer bereitstehen.

Bei der Auswahl des Raumes ist darauf zu achten, dass alle Teilnehmer die Demonstration gut sehen können. Entsprechend sollte ein ausreichend großer Raum reserviert werden. Falls räumlich möglich, eignet sich hierfür auch ein Entwicklerbüro, da Entwicklern die Präsentation in "heimischen Gefilden" oft leichter fällt.

Benötigte Hilfsmittel, um das Inkrement zu präsentieren:

  • Rechner und Software zur Darstellung von Programmen oder Funktionen
  • bei Bedarf Betriebsmittel zur Präsentation von mechanischen Elementen

 

Durchführung ...

Praxistipps ...

Varianten ...

Herkunft

Scrum wurde in den frühen 1990er Jahren durch Ken Sutherland und Ken Schwaber erdacht (veröffentlicht unter dem Namen: "SCRUM Software Development Process"). Die Ausarbeitung der Idee basiert auf der Publikation "New New Product Development Game", in der Hirotaka Takeuchi und Ikujiro Nonaka 1986 die Entwicklung eines gemeinsamen Ziels durch Iterationen beschrieben. Besondere Schwerpunkte waren hierbei Geschwindigkeit und Flexibilität. Die aktuell gültige Version von Scrum ist im sogenannten "Scrum Guide" dokumentiert, der in mehreren Sprachen frei zum Download auf der Website www.scrumguides.org zur Verfügung steht.

Fachartikel zur Methode

Viele Software-Produkte entsprechen nach Fertigstellung nicht den Vorstellungen des Kunden.
Scrum schreibt als agile Projektmanagement-Methode nur wenige Rollen, eine überschaubare Menge an Regeln und wenige Dokumente vor. So wirkt die Anwendung von Scrum auf den ersten Blick bestechend einfach.
Teil 1:
Projektinitiierung und Planung
Für IT-Projekte bringt die Scrum-Methodik viele Vorteile, der Einsatz in SAP-Entwicklungsprojekten scheint daher naheliegend. Doch in der Praxis bestehen hier einige Herausforderungen. So birgt z.B.
Teil 2:
Projektdurchführung und Ausblick
Im ersten Teil haben Sie erfahren, was es bei der Vorbereitung und Planung von Scrum in SAP-Projekten zu berücksichtigen gilt.
User Stories beschreiben Anforderungen an eine Software aus Sicht des Nutzers. Obwohl sie einen klaren, einfachen Aufbau haben, gilt es bei der Konzeption einiges zu beachten.
Die Euphorie bei der Einführung von Scrum ist oft groß – verspricht man sich doch von Scrum eine höhere Wirtschaftlichkeit und innovativere Produkte. Doch in manchen Fällen macht sich schnell Ernüchterung breit.

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
4 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 5
Kommentare 4

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.