Der Ablauf des Sprint Reviews

Das Sprint Review findet am Ende eines Sprints statt. Ziel des Meetings ist es, zusammen mit den Stake-holdern neue Ideen für die weitere Gestaltung des Produkts zu gewinnen. Dazu werden in der Regel bei einem vierwöchigen Sprint ca. vier Stunden angesetzt. Bei einem zweiwöchigen Sprint plant man zwei Stunden ein.

Der Scrum Master koordiniert die Einladungen zum Review. Dies kann in Zusammenarbeit mit dem Product Owner erfolgen, denn am Sprint Review können neben den Mitgliedern des Scrum Teams auch Stakeholder teilnehmen. So können sich diese ein Bild vom aktuellen Status des Produkts machen und Feedback dazu geben.

Der Product Owner und das Entwicklungsteam stellen das neue Produktinkrement vor. Dazu gehören alle Items, die im letzten Sprint komplett umgesetzt wurden und somit den Status „done“ besitzen. Die Items haben das Quality Gate der Definition of Done durchschritten und sind auslieferbar. Für die Vorstellung des Produktinkrements erarbeitet das Entwicklungsteam vorab ein Drehbuch. Dies enthält die Reihenfolge der vorzustellenden Items sowie denjenigen, der ein Item vorstellt. Daneben werden die benötigten Testumgebungen und Testdaten vorbereitet. Die Funktionalitäten werden anhand der Akzeptanzkriterien vorgeführt.

Es kann vorkommen, dass nicht alle Items im Sprint geschafft wurden. Um aus den Gründen dafür zu lernen, erläutert das Entwicklungsteam auch entsprechende Hindernisse im Sprint. Dies macht natürlich auch Sinn, wenn alle Items geschafft wurden. Daraus kann gelernt werden, ob das Produkt so umgesetzt werden kann, wie sich der Product Owner es vorstellt, oder ob weitere oder andere Aufgaben notwendig sind, um das Produkt weiterzuentwickeln. Das Product Backlog wird dementsprechend angepasst.

Daneben kann es sein, dass aus der Präsentation des neuen Inkrements Ideen entstehen, die ebenfalls im Product Backlog aufgenommen werden. Die Produktvision kann sich durch neue Erkenntnisse ändern.

Trotz der sorgfältigen Vorbereitung und des genauen Ablaufs des Sprint Reviews, sollte dies stets zwanglos und informell ablaufen. Es unterstützt die Transparenz und Kommunikation zwischen Kunden und Entwicklern und sorgt für Feedback zwischen allen Beteiligten. Der Product Owner kann das Backlog verbessern, die Stakeholder lernen das neue Produkt kennen und die Entwickler bekommen direkte Rückmeldung zu ihrer Arbeit und einen Überblick darüber, wie das Produkt weiterentwickelt werden soll. Jeder Beteiligte hat somit einen Mechanismus zur kontinuierlichen Anpassung der eigenen Planung.

Verfasst von Konstanze Steinhausen am 12. April 2017