Theorie "Sprint Review"

Überprüfung der Increments dieses Sprints¶

Nachdem das Sprinting abgeschlossen ist, findet das Sprint Review statt. Wie Sie bereits aus den vorherigen Kapiteln wissen, ist dies ein offizielles Scrum Event. Der Zweck des Sprint Reviews ist, die Ergebnisse des Sprints zu überprüfen und zukünftige Anpassungen festzulegen. Hier erfolgt die Abnahme der Increments, es wird überprüft, ob das Sprint Goal erreicht wurde und der Fortschritt in Richtung Product Goal wird diskutiert.

Vor dem Sprint Review¶

Der Scrum Master ist dafür verantwortlich, dass das Sprint Review Meeting geplant und durchgeführt wird. Im Zuge dessen lädt er den Product Owner ein sowie jeden, der Interesse hat, am Sprint Review teilzunehmen. Der Product Owner muss zum Sprint Review erscheinen, ob allerdings die anderen Eingeladenen auch zum Sprint Review kommen, entscheiden diese häufig selbst. Sie machen die Entscheidung davon abhängig, ob im Sprint Review Themen besprochen werden, die für sie von Interesse sind, oder nicht. Daher ist es sinnvoll, schon vorab eine Liste mit all den User Stories, die abgeschlossen wurden und vorgestellt werden, zu verschicken. So können die Stakeholder besser entscheiden, ob sie die Teilnahme am Sprint Review als sinnvoll erachten, oder nicht.

Live-Demo, keine einfache Präsentation¶

In diesem Meeting stellen die Developer den Stakeholdern die Ergebnisse vor, die im aktuellen Sprint erarbeitet wurden. Wie schon das Daily Scrum Meeting, ist auch das Sprint Review Meeting weder Statusmeeting noch Berichterstattung! Im Scrum gibt es kein explizites Reporting. Da im Sprint Review den Stakeholdern und dem Product Owner das neueste Increment vorstellt wird, kann gesagt werden, dass das Sprint Review die Berichterstattung im allerweitesten Sinne ersetzt.

Die Vorstellung des Increments erfolgt nicht durch eine Powerpoint-Präsentation oder Ähnliches. Das Increment, welches potenziell auslieferbar ist, wird als solches in einer Live-Demo vorgestellt und getestet. Die Vorstellung ist demnach nicht theoretisch, sondern praxisnah. Fragen zum Increment sind ausdrücklich erwünscht.

Das Sprint Review kann aus diesem Grund auch in den unterschiedlichsten Räumen abgehalten werden. Es bietet sich zum Beispiel an, das Sprint Review in einem Labor durchzuführen, wenn auch die Entwicklungsarbeiten in einem Labor stattgefunden haben. Falls die Developer hauptsächlich in einem bestimmten Büro gearbeitet haben, könnte man sich für das Sprint Review auch in diesem Büro treffen.

Da die Developer das Increment den Anwesenden vorstellen, sollten alle Developer über grundlegende Präsentationsfähigkeiten verfügen. Eine weniger gute Vorstellung des Increments kann dazu führen, dass die Stakeholder mit den Ergebnissen nicht zufrieden sind - daher sollte sichergestellt sein, dass die Vorstellung nicht an der Art und Weise der Präsentation scheitert.

Testen und klares Feedback¶

Der Product Owner wird dazu angehalten, das Increment zu testen. Akzeptanztests dienen dazu dem Kunden zu zeigen, dass das Increment nutzbar ist und welche Aufgaben die Developer noch zu erledigen haben. Es ist wichtig, dass der Product Owner aktiv am Sprint Review teilnimmt, denn die Developer benötigen das Feedback, um sich in den kommenden Sprints kontinuierlich zu verbessern. Hier ist sowohl Lob als auch Kritik wichtig. Doch nicht nur der Product Owner darf Feedback geben: Auch die anderen Stakeholder sind eingeladen konstruktives Feedback abzugeben. Je mehr Feedback die Developer während des Sprint Reviews bekommen, desto besser ist es. Der Vorteil des Feedbacks während des Sprint Reviews ist, dass es die Developer ohne Zwischenstufen erreicht. Sie hören direkt von der testenden Person und von den Stakeholdern, was gut und was weniger gut am Increment ist. Über dieses Feedback sollte ein Protokoll geführt werden, sodass die Ergebnisse des Meetings auch in schriftlicher Form festgehalten werden.

Akzeptanzkriterien¶

Im Kapitel User Stories, Epics, Product Backlog Items haben Sie gelernt, dass Akzeptanzkriterien definiert und festgehalten sein müssen, sodass die entsprechende User Story abgenommen werden kann.

1
2
3
4
5
6

- <strong>I</strong>ndependent
- <strong>N</strong>egotiable
- <strong>V</strong>aluable
- <strong>E</strong>stimable
- <strong>S</strong>mall
- <strong>T</strong>estable

1
2
3

- <strong>C</strong>lear 
- <strong>T</strong>estable
- <strong>F</strong>easible

Im Sprint Review kommen die vorher festgelegten Akzeptanzkriterien zur Anwendung: Denn basierend darauf wird der Product Owner entscheiden, ob er die User Story abnimmt, oder nicht.

"Done" oder nicht "Done"¶

Während des Sprint Reviews werden alle Items präsentiert, die laut der Definition of Done "Done" sind.

PBIs, die nicht zu hundert Prozent fertig sind, werden nicht vorgestellt und können auch nicht abgenommen werden - auch wenn sie zum Großteil fertig sind. Eine partielle Abnahme von Increments kann nicht erfolgen. Bis zum Sprint Review nicht abgeschlossene oder fehlerhaft abgeschlossene Tasks bzw. User Stories und Einträge, welche vom Product Owner nicht akzeptiert werden, wandern zurück ins Product Backlog. Dort werden sie repriorisiert und gegebenenfalls im nächsten Sprint zu Ende geführt. Einträge, die defekt oder als „Technical Debt" gekennzeichnet sind, werden entweder sofort umgesetzt, oder als Backlog Item identifiziert und entsprechend der Dringlichkeit und des Kritikalitätsgrades bearbeitet.

Nachdem der Product Owner die User Stories abgenommen hat, wird das Umfeld auf etwaige Veränderungen hin analysiert und, falls nötig, werden Anpassungen am Product Backlog vorgenommen. Auch das Feedback der Stakeholder oder des Product Owners kann zu Ergänzungen des Product Backlogs führen. Die Ergebnisse des Meetings geben den Developern Feedback zu der bisher erledigten Arbeit und gewährleisten, dass Informationen zu nachfolgenden Tätigkeiten bereitgestellt werden.