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
★★★★★
★★★★★
5
Kommentare 4
Zuletzt aktualisiert am
PDF-Download (English)
PDF-Download

Themen

Alle Themen

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

 

  1. Schritt 1: Scrum Master und Product Owner bereiten den Sprint Review vor
  2. Schritt 2: Scrum Master und Product Owner eröffnen das Review
  3. Schritt 3: Product Owner moderiert das Review
  4. Schritt 4: Product Owner und Scrum Master schließen das Review
Alle Schritte im Detail

Durchführung ...

Praxistipps ...

Varianten ...

Ergänzende Methoden

Aufgabengebiete

Berichten & Dokumentieren
Präsentieren & Moderieren
Überwachen & Steuern

Keywords

Lessons learned
Scrum
Agile
Bewerten
Steuern
Teamführung

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.

Links

Bradley, Charles: Tips for a Good Sprint Review (ScrumCraczy.com)
Mamoli, Sandy: A template fort he sprint review (nomad8.com)
van Solingen, Rini: How to improve your Sprint Review meeting? (rinivansolingen.nl)
Rubin, Ken: Diskussion bzgl. des Begriffs "Demo"
Schwaber, Ken u. Sutherland, Jeff: The Scrum Guide

Fachartikel zur Methode

Scrum – eine Einführung

Viele Software-Produkte entsprechen nach Fertigstellung nicht den Vorstellungen des Kunden.
Zum Artikel

Häufige Stolperfallen in Scrum

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.
Zum Artikel

Scrum in SAP-Projekten einsetzen

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.
Zum Artikel

Scrum in SAP-Projekten einsetzen

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.
Zum Artikel
Vorschaubild

So vermeiden Sie Stolpersteine bei User Stories

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.
Zum Artikel

Kein Erfolg mit Scrum – vier Gründe für das Scheitern

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.
Zum Artikel

Bewertungen und Kommentare

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

Themen

Alle Themen

Mehr zum Thema

Mit Projekten in die Zukunft: 3. So messen und steuern Sie erfolgreich

Wie messen Sie den Erfolg Ihres Zukunftsprojekts? Viele Unternehmen neigen dazu, die gleichen Metriken und Meilensteine, die sie ihrem Tagesgeschäft benutzen, auch für Projekte anzuwenden.

Zum Blog
Vorschaubild

Berichten und Dokumentieren: schlank und aussagekräftig

E-Book mit 151 Seiten, 4 Methoden und 4 Arbeitshilfen
Zum E-Book

Artikel

So etablieren Sie Demos als Ersatz für Statusmeetings

Retrospektiven mit der WADE-Matrix strukturieren

Agile Controlling – aussagekräftiges Berichtswesen für agile Organisationen

Projektreview mit Schwachstellenanalyse

"After Action Review" – Lessons learned für Zwischendurch

TOC-Denkprozesse: Gegenwartsbaum zur Konfliktlösung einsetzen

Lessons learned – aus Fehlern in Projekten lernen

Reviews - der erste Schritt zur projektbegleitenden Qualitätssicherung

Vorschaubild

Team Estimation Game

Mittels kollektiver Betrachtung schätzen Sie mit hoher Genauigkeit und dank des kurzen und intuitiv verständlichen Regelwerks mit geringem Aufwand. Die Gestaltung als Spiel fördert die aktive Mitarbeit in der Gruppe.
Zur Methode
Übung Veränderungsbereitschaft ermitteln

Übungen: Veränderungsbereitschaft ermitteln

Mit der Veränderungsformel erkennen Sie eigene Vorbehalte sowie Widerstände der Projektbeteiligten gegenüber Change Projekten und leiten passgenaue Maßnahmen zur Überwindung ab. Mit zwei Übungen zum Artikel und Beispielen können Sie sich und die anderen Projektbeteiligten einschätzen lernen.
Zum Tool

Mehr zum Thema

ControllingTeamführungInformation

Alle Kommentare (4)

Guest

25.07.2018

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.

 

  • Anmelden, um Kommentare verfassen zu können
Profile picture for user Angermeier
Georg
Angermeier
Dr.

25.07.2018

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

 

  • Anmelden, um Kommentare verfassen zu können
Peter
Müller

26.12.2018

★★★★★
★★★★★
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.

 

  • Anmelden, um Kommentare verfassen zu können

26.12.2018

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.

 

  • Anmelden, um Kommentare verfassen zu können