Die Sprint Review ist ein Event, das am Ende des Sprints stattfindet und bei dem das Team sein potenziell releasefähiges Produkt präsentiert. Das Ziel des Sprints ist es, an einen Punkt zu gelangen, an dem sie ein Produkt haben, das codiert, getestet und in die Produktion gegeben werden kann. Der Zweck dieses Treffens ist es, das Produkt zu inspizieren. Der Product Owner wird in der Regel alle relevanten Stakeholder einladen, um das Produkt zu überprüfen und dem Team Feedback zu geben. Nach außen hin scheint dies eines der einfachsten Treffen in Agile oder Scrum zu sein – aber in Wirklichkeit ist es eines der heikelsten.

Vorbereitung

Eine gute Vorbereitung ist der Schlüssel zu diesem Meeting. Ein Teil des Meetings kann eine Demo des Produkts sein, also bereitet der Product Owner im Idealfall einen Durchlauf vor. Es ist sicherzustelle, dass alles eingerichtet und konfiguriert ist. Der Computer, auf der die Demo durchgeführt wird, sollte während der Präsentation keine automatischen Updates installieren. Jeder sollte wissen, was die Definition of Done ist! Das Treffen hat wenig Sinn, wenn nicht alle wissen, was „done“ beduetet. Die Sprint Review liegt in der Verantwortung des Product Owners. Der Product Owner stellt sicher, dass alle am Treffen teilnehmen. Das Meeting sollte Spaß machen. Bringe Getränke und Snacks mit, inklusive Aktivitäten oder Teilnahme. Dadurch fühlen sich die Menschen entspannter und können einige dieser kritischen Rückmeldungen gewinnen.

Der Scrum Master kann ihm hierbei jedoch unterstützend und moderierend zu Seite stehen. Er kann vor dem Meeting, Informationen über den letzten Sprint und dem anstehenden Event versenden, beispielsweise die eben erwähnte Definition of Done. Das Meeting erfordert außerdem einen neutralen Moderator. Der Scrum Master stellt sicher, dass das Meeting auf Kurs bleibt, identifiziert und löst Konflikte. Jede Sprint Review wird anders sein, mit verschiedenen Stakeholdern gilt es verschiedene Entscheidungen zu treffen. Das Event sollte strukturiert sein, eine Agenda kann vorbereitet und sichtbar aufgehängt werden. Ein gutes Beispiel für eine Agenda könnte sein:

1. Der Scrum-Master startet das Meeting und erinnert alle an die Regeln
2. Der Product Owner präsentiert das Sprintziel und was er vom Sprint erwartete, einschließlich des Projektfortschritts und des Gesamtbildes.
3. Das Team überprüft den Sprint und die wichtigsten Informationen.
4. Das Team demonstriert die User StoriesDer Product Owner eröffnet eine Diskussion mit dem Team und den Stakeholdern, um Feedback zu sammeln.
5. Der Product Owner schließt mit einer kurzen Zusammenfassung und einem Plan, was als nächstes zu tun ist.

Das Event

Verantwortung

Der Product Owner leitet das Meeting. Er sollte die volle Autorität über das Produkt haben, was erforderlich ist und was getan werden muss. Wenn Stakeholder die tatsächlichen Entscheidungen treffen (und nicht nur beeinflussen), wird die Rolle des Product Owners überflüssig. Der Product Owner kann das Event starten, indem er das Sprint-/Release-Ziel überprüft und einen Überblick über die Anforderungen gibt

Organisatorischer Rahmen

Wie bei allen Scrum Event ist die Sprint Review timeboxed. Sie sollte für jede Woche, die der Sprint hat, eine Stunde betragen. Es gibt weitere Einschränkungen wie die Größe und Verfügbarkeit von Besprechungsräumen, Zeitpläne der Teilnehmer oder andere Probleme, die sich auf die Besprechung auswirken können. Der erste Instinkt ist, das Event zu verschieben. Tu das nicht. Wenn das Meeting verschoben wird, stört das die notwendige Routine. Es ist enorm schwierig, das Meeting dann wieder in Gang zu bringen. Wenn die Besprechung mit den minimal benötigten Personen durchführbar ist, dann wird sie durchgeführt. Personen, die nicht teilnehmen können, informiert man im Nachgang.

Formeller Rahmen

Die Sprint Review ist kein Update-Meeting um zu überprüfen, wie viel Arbeiten abgeschlossen sind.Ein gutes kollaboratives Scrum-Team sollte den Stand der Arbeit sowieso kennen. Wenn nicht, was passiert in den Daily Scrums? Das Meeting sollte informell sein. Es ist die Möglichkeit, Feedback zu bekommen und zu geben. Die Atmosphäre ist sehr wichtig. Es sollte eine Umgebung des Vertrauens und des Komforts geben. Das Team sollte das Selbstbewusstsein entwickeln können, um zu sagen, wenn es noch nicht fertig ist. Ansonsten ist sehr schnell festzustellen, dass die Qualität der Ergebnisse abnimmt und die technische Verschuldung steigt.

Inhalt

Eine allgemeine Regel im Sprint Review ist, dass keine Folien erlaubt sind. Kein Sprint Review sollte mit einer PowerPoint-Präsentation von Screenshots mit funktionierender Software durchgeführt werden. Wenn das Produkt demonstriert werden soll, dann sollte es funktionieren. Die Demo sollte auch in der Umgebung durchgeführt werden, die der Produktion am nächsten ist. Wenn Sie neue mobile Funktionen freigeben, sollten Sie diese auf einem Handy testen. Es sollte auch kein Schummeln geben. Es widersetzt sich dem gesamten Zweck des Treffens und wird keinen Wert haben. Wenn etwas nicht funktioniert, muss die Ursache untersucht werden, damit sich das Team richtig anpassen kann. Es ist wichtig, nützliche und wertvolle Software zu zeigen und den dazu Kontext zu liefern.

Feedback der Stakeholder

Es muss sichergestellt werden, dass die richtigen Stakeholder anwesend sind. Das Treffen sollte einnehmend und wertvoll sein. Es gibt nichts Schlimmeres als nicht engagierte oder unmotivierte Stakeholder, die sich mit Anwendergeschichten beschäftigen, an denen sie kein oder nur wenig Interesse haben. Jedes Feedback ist willkommen. Der Produkteigentümer sollte versuchen, so viel wie möglich von den Stakeholdern zu erfahren. Es sollte viele Rückmeldungen und Ideen geben, wie man vorankommt. Dies bietet dem Product Owner die Chance, sie in seinen Produkt-Backlog aufzunehmen.

Aufgabe des Scrum Masters während des Events

Der Scrum Master hat keinen inhlatlichen Input zur Besprechung. Er sorgt dafür, dass die Regeln und Praktiken von Scrum eingehalten werden. Es ist keine Retrospektive, also sollte sich die Diskussion nicht um Prozessverbesserungen drehen. Bei dieser Methode geht es um das WAS, bei Retrospektiven um das WIE. Diese Treffen werden oft miteinander vermischt, was falsch ist.

Die Sprint Review abschließen

Am Ende des Treffens ist es wichtig, dass das Gesamtprojekt besprochen wird und was als nächstes zu tun ist. Das verbleibende Backlog sollte überprüft und diskutiert werden, was fehlt und was angepasst werden muss. Beachte, dass im Idealfall alle Stakeholder zum Event anwesend sind. Dies sind oft hochrangige Personen im Unternehmen und wichtige Entscheidungsträger. Der Product Owner überprüft das Product Baklog und fordert Feedback der Stakeholder ein. Was als nächstes zu tun ist, kann eine kurze Diskussion am Ende des Treffens sein.

Der Product Owner sollte zudem versuchen, das Event zu messen. Ein Feedback oder einen allgemeinen Konsens über den Verlauf des Treffens sollte dokumentiert werden, um es beim nächsten Mal noch besser zu machen.Man sollte auch nicht vergessen, Erfolge zu feiern. Obgleich die Sprint Review kein Event ist, bei dem man wild mit Lobpreisungen um sich werfen sollte, gilt es trotzalledem das Geleistete anzuerkennen und die moralische Einstellung des Teams  zu fördern.

Bingo

Solltest du das Gefühl haben, die Sprint Review läuft nicht so wie sie sein sollte, gibt es hier das Sprint Review Bullsh*t Bingo. Die aufgeführten Beispiele gilt es unter allen Umständen zu vermeiden.

Einen Überblick zur Serie Scrum Basics findest du hier: Scrum Basics: Alles auf einen Blick