Am Ende eines Sprint findet das meist zweistündiges Sprint-Review statt. (Für detaillierte Zeiteinschätzungen siehe Sprint, Zeitplanung.) Nach einem Sprint wird das Sprint-Ergebnis einem informellen Review durch Team und Kunden unterzogen. Dazu wird das Ergebnis des Sprints (die laufende Software) vorgeführt, eventuell werden technische Eigenschaften präsentiert. Der Kunde und/oder der Product Owner prüft, ob das Sprint-Ergebnis seinen Anforderungen entspricht, eventuelle Änderungen werden im Product Backlog dokumentiert.
Zielsetzung des Sprint Review
Ziel des Sprint Reviews ist die Begutachtung der entstandenen Arbeitsergebnisse und den Projektfortschritt transparent zu machen. Der Product Owner prüft ob alle Anforderungen im Sprint Backlog korrekt (vollständig und fehlerfrei) umgesetzt wurden. Das Produkt wird also inspiziert und das nächste Sprint Ziel kann adaptiert werden.
Teilnehmer
Teilnehmer sind das Team, Product Owner und Scrum Master sowie optional Interessenvertreter, wie Endanwender, Kunde, Repräsentanten, etc..
Kunden und Endanwender können hier ungefiltert und direkt Verbesserungsvorschläge und Feedback einbringen.
Ablauf des Review
Der Scrum Master lädt zum Sprint Review ein und moderiert diesen. Ein fester Zeitrahmen ist entsprechend vorgegeben. Nur eine minimale Vorbereitung ist vorgesehen.
- Reflektieren des Sprint Ziels und der als umgesetzt erwarteten Anforderungen
- Team führt die umgesetzten Anforderungen möglichst in einer Live-Demo vor
- Product Owner sollte selbst Tests durchführen können
- Benutzerhandbücher und Dokumentation sollten entsprechend auch einsehbar sein
- Fragen und Feedback von Product Owner und Interessenvertretern
- Product Owner nimmt das Ergebnis an oder lehnt es ab (eine Anforderung kann nur abgenommen werden, wenn sie zu 100% fertiggestellt ist. Bugs oder 99%ige fertigstellung bedeuten das Ablehnen der Anforderung und die Aufnahme in den Product Backlog mit hoher Priorität, um sie im nächsten Sprint fertig zu stellen.)
Als Product Owner können zum Qualitätssicherung entsprechende Nachweise verlangt werden:
- Testprotokolle der letzten offiziellen Softwareproduktion (Welche Tests wurden durchgeführt und waren sie Erfolgreich?)
- Testabdeckung (Erfüllt die Testabdeckung die Anforderungen?)
- Refaktorisierungspotenzial und Komplexität der Software (Im Vergleich zum letzten Sprint)
- Kodierrichtlinientreue (Sind die vereinbarten Kodierrichtlinien umgesetzt?)
Typische Fehler
- Passiver Product Owner – Als Product Owner nicht passiv einfach die Ergebnisse abnicken, aktiv die Arbeitsergebnisse begutachten
- Einzelne Teammitglieder nicht loben oder tadeln, dies untergräbt die Autonomie des Teams
- Probleme und Fehler klar ansprechen. Ablehnen von fehlerhaften Anforderungen klar begründen
- Product Review nicht zu einer „Zaubershow“ für Kunden ausweiten sondern sachlich eine Bestandsaufnahme vornehmen (keine Prototypen)
- Nur Abnahmen auf der offiziellen Testumgebung annehmen. Ein privates Build dient nicht zur Bewertung ob Anforderungen adäquat umgesetzt wurden
