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.
Autor
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.
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.
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.
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
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.
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.
Schritt 2: Scrum Master und Product Owner eröffnen das Review
Zu Beginn des Sprint Reviews stellt der Scrum Master die Teammitglieder und den Ablauf des Meetings vor. Es empfiehlt sich besonders bei großen Teilnehmerzahlen eine Agenda mit klaren Zeitvorgaben. Anschließend berichtet der Product Owner kurz, welche Produkte bzw. Produktinkremente während des vergangenen Sprints gemäß der Definition of Done erstellt wurden. Er erläutert darüber hinaus das Sprintziel im Gesamtkontext des Projekts. Es muss deutlich werden, dass der Sprint Review "das Meeting" des Product Owners ist. So sollte der Product Owner den bislang erzielten ROI (Return on Invest) des erstellten Produkts beleuchten. Ebenfalls ist es sinnvoll, das Publikum zu konstruktivem Feedback während des Sprint Reviews zu ermutigen.
Jetzt kostenlos weiterlesen!
1 Monat
kostenlos und unverbindlich testen
- Management Summaries und Zugriff auf über 1800 Fachartikel.
- Methoden, Tools und Vorlagen
- Riesiges Archiv und jede Woche neue Inhalte!
- Kostenlos und ohne Risiko einen Monat lang testen
Praxistipps ...
Ergänzende Methoden
Fachartikel zur Methode
Aufgabengebiete
Links
Jetzt Feedback geben und mitdiskutieren!
Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.
Frank Bauer
25.07.2018
Angermeier
25.07.2018
Peter Müller
26.12.2018
Dr. Georg Angermeier, Redakteur Methoden
26.12.2018