Sprint Review

Zu den elementaren Meetings in Scrum gehört neben Planning (1 und 2), den Dailies und der Retrospektive auch das Sprint Review. Ein gut vorbereitetes Sprint Review, in dem lauffähige Software in einem geschäftlichen Kontext demonstriert werden kann, ist der gelungene Abschluss eines Sprints.

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.

— Scrum Guide

image

Warum ist ein gutes Sprint Review wichtig?

Ein gutes Sprint Review ist nicht nur ein Meeting in dem es darum geht, Arbeitsergebnisse abzunehmen, sondern hier werden die erstellten Lösungen in einen Kontext gebracht: Es wird nochmals die Zielsetzung des Inkrements reflektiert und erläutert, warum die geplanten Ergebnisse wichtig für die Organisation sind. Hierdurch wird allen Beteiligten nochmals in Erinnerung gerufen, warum das Inkrement so geplant wurde. Das Umsetzungsteam hat zudem die Möglichkeit, gemachte Erfahrungen und Herausforderungen sowie besondere Leistungen und Lösungen vorzustellen.

Damit spiegelt das Review nicht nur die Arbeit des letzten Sprints wieder, sondern ist auch ein Hilfsmittel für die kommenden Sprints bzw. die weitere Zusammenarbeit innerhalb eines Teams.

Im Review trifft die Sichtweise des Auftraggebers (PO) und des Umsetzungsteams aufeinander und es findet ein intensiver Austausch statt. Die Vorstellung des Business hinsichtlich Zielsetzung und Anforderungen werden ebenso erörtert wie die durch das Umsetzungsteam gewählten Lösungsvariante. Hierbei können beide Seiten voneinander lernen, gegenseitiges Verständnis verbessern und das Gelernte in kommende Sprints einbringen.

Teilnahme Review

Die Teilnahme am Review ist für alle Auftraggeber (die eine Story im Sprint haben) grundsätzlich verpflichtend, da im Review geklärt werden muss, ob die geplanten Themen wirklich erledigt und die Zielsetzung des Inkrements erreicht wurde.

Im optimalen Fall, kann der Product Owner alle Themen inhaltlich komplett bewerten. Bei Themen deren Fachlichkeit nicht alleine durch den Product Owner bewertet werden kann, muss der Auftraggeber direkt eingebunden werden. Sollte in diesem Fall ein Auftraggeber zum Review-Termin verhindert sein, so stimmt er sich mit dem Product Owner ab, wie die Abnahme geschehen soll. Bei komplexen User Stories sendet der Auftraggeber einen Vertreter der die User Story abnehmen kann. Sollte die Abstimmung nicht erfolgt sein und kein Auftraggeber/Vertreter am Review teilnehmen, so wird die User Story nach einfacher „Sichtprüfung“ geschlossen. Dies bedeutet jedoch nicht, dass sie automatisch Teil des nächsten Release wird. Es kann passieren, dass sich die Auslieferung durch die fehlende Abstimmung signifikant verzögert.

Bei komplexeren Stories, muss der Product Owner bzw. Auftraggeber schon vor dem eigentlichen Review intensiv eingebunden werden (“collaborate on a daily basis”), da nur so eine “Abnahme” im Review erteilt werden kann.

Ablauf eines Sprint Reviews

Der Scrum Master organisiert in Abstimmung mit Product Owner das Meeting (Raum, Ausstattung, Einladungen etc) und übernimmt während des Reviews lediglich die Rolle eines Moderators. Er achtet auf Einhaltung der Timebox und darauf, dass der Fokus nicht verloren geht.

Der Product Owner fasst die Zielsetzung (“Sprint Goal”) des Sprints und die umgesetzte Funktionalität zusammen. Hierfür geht er auch auf Besonderheiten einzelner Stakeholder ein. Er erläutert, welchen Mehrwert das Inkrement für das Unternehmen darstellt. Zusammen mit den Scrum Master geht er auf mögliche Besonderheiten ein und dankt bei einem erfolgreichen Sprint dem Umsetzungsteam für den Einsatz.

Alle Themen in Bezug auf die Umsetzung sollten im Sprint Review durch das Umsetzungsteam präsentiert werden. Hierfür erläutert das Umsetzungsteam in Zusammenspiel mit dem Product Owner die umgesetzten Stories (Zielsetzung, Akzeptanzkriterien, How to Demo) und führt die gewünschte Funktionalität (“working, tested code”) vor. Hierbei ist darauf zu achten, dass die Definition of Done eingehalten und die Akzeptanzkriterien erfüllt wurden.

Der Product Owner hat das Recht bei Fehlern oder Abweichung von der Definition of Done die Abnahme zu verweigern. In diesem Fall muss das Umsetzungsteam nachbessern, die fehlerhafte Story wird nicht abgenommen und die StoryPoints werden nicht gezählt.

Nicht abgenommene Stories werden auch nicht in ein Release übernommen. Der Product Owner entscheidet ob diese im kommenden Sprint oder zu einem späteren Zeitpunkt umgesetzt werden sollen.

Es folgt die Zusammenfassung des Sprints und des Projektstatus. Die ermittelte Velocity fließt in die Ist-Bewertung des Projektfortschritts ein. Der Product Owner trifft Aussagen zum Projektstatus (Soll/Ist) und gibt einen Ausblick auf kommende Sprints, deren Ausrichtung/Zielsetzung auch diskutiert werden kann.

Eine Danksagung an die Teilnehmer und alle an dem Sprint Beteiligten schließt das Review ab.

Beispielagenda

Teilnehmer: Umsetzungsteam, Product Owner, Stakeholder, Scrum Master (Moderator)

  • Begrüßung durch Product Owner oder Scrum Master
  • Business Context
    • Product Owner stellt Zielsetzung (Sprint Goal) und die Themen vor
    • Besonderheiten werden (durch SM oder PO) vorgestellt (Möglichkeit für Danksagung)
    • Zusammenfassung des Ergebnisses
      • war der Sprint ein Erfolg?
      • wie wurde vorgegangen?
      • gab es neue Erkenntnisse?
  • Demonstration des Inkrements
    • DevTeam führt die Funktionalität vor (How2Demo, Akzeptanzkriterien)
      • Diskussion / Frage & Antwort
      • Feedback der Stakeholder
    • Diskussion identifizierter Herausforderungen/Risiken
  • Der Product Owner entscheidet ob das “SprintGoal” erreicht worden ist
  • Nur im Review abgenommene Stories werden in das nächste geplante Release übernommen!
  • Zusammenfassung
    • Aktualisierung der Metriken, Ermittlung der erzielten Velocity, Vergleich von geplanten/abgenommen Stories und StoryPoints.
    • Darstellung Projektfortschritt (Release-Burndown etc)
    • Ausblick und Diskussion kommender Sprints
  • Danksagung & Abschluss

Empfehlungen

Einige Empfhelungen für die Durchführung von Reviews:

  • Ein Sprint Review sollte für einen 2-wöchigen Sprint nicht länger als 1-2 Stunden dauern
  • Die Vorbereitung des Reviews durch das Team sollte ebenfalls nicht mehr als 1-2 Stunden benötigen.
    • Demonstration potentiell auslieferbarer Software (die der Definition of Done entspricht) statt Powerpoint Präsentationen
    • Einfache Hilfsmittel zur Unterstützung der Durchführung des Reviews, z.B. Wiki-Seite mit Links auf Software, Login-Daten etc. So wird keine Zeit verschwendet (“Wie war der Link nochmal?”).
  • Die Teammitglieder präsentieren nicht ausschließlich dem Product Owner sondern auch den teilnehmenden Stakeholdern
  • Eine intensive Interaktion (Diskussion) mit teilnehmenden Stakeholdern über die gewählten Lösungen hilft allen Beteiligten zu verstehen, wie gut die Zielsetzung erreicht wurde.
  • Ein Sprint Review darf – und sollte Spass machen!

Zusammenfassung

In einem Sprint Review spielt der Kontext – formuliert durch den Product Owner – eine wichtige Rolle. Nur durch den Kontext ergeben die umgesetzten Lösungen (wirtschaftlichen) Sinn. Das Umsetzungsteam demonstriert die gewählten Lösungsansätze selbstständig und weist auf Herausforderungen und besondere Leistungen hin. Eine intensive Diskussion aller Beteiligten führt dazu, dass das gegenseitige Verständnis sich verbessert und so zukünftige Planungen verlässlicher werden.

Über Felix Rüssel

Felix Rüssel is exploring Lean-Agile concepts since 2002 with a special focus on how to connect and align Business and Development on all levels of an organization. He likes to challenge established thinking patterns and structures to enable innovative approaches which help to deal with current and future challenges. Felix Rüssel is a Certified Scrum Professional (CSP-PO), a Certified LeSS Practitioner (CLP) and a SAFe Program Consultant Trainer (SPCT5).