Die sichtbarste Aktivität während der Sprint Review ist eine Demonstration der während des Sprints gebauten Funktionalitäten. Eine gute Sprint Review beinhaltet jedoch mehr als nur eine Demo. Ziel ist es, die Interessengruppen transparent über geleistete, nicht geleistete, hinzugefügte und aus dem Sprint entfernte Arbeiten zu informieren. Außerdem bittet man Stakeholder aktiv, Feedback zu geben. Der große Vorteil ist der Austausch zwischen dem Team und den Interessengruppen.

Die Sprint Review beginnt vor der Sprint Review

Es ist wichtig, sich vorzubereiten. Es macht Sinn, einen Probedurchlauf zu durchlaufen, bevor man die Software einem größeren Publikum zur Verfügung stellt. Somit kann sichergestellt werden, dass sie funktioniert und dass alle Konten, Logins und Daten eingerichtet sind.

Begrüßung, die Grundregeln und das Sprintziel

Der Product Owner beginnt damit, dass er alle zur Sprint-Review begrüßt. Das kann so einfach sein, wie zu sagen: „Danke, dass ihr alle hier seid“. Wenn die Teilnehmer sich gegenseitig nicht kennen, kann hilfreich sein, diese kurz vorzustellen bzw. sich vorstellen zu lassen. In vielen Unternehmen ist das Sprint Review Meeting das einzige Mal, dass bestimmte Teammitglieder miteinander interagieren. Nach einer ersten Begrüßung kann der Product Owner Grundregeln und Erwartungen für die Sprint Review teilen. Ein Product Owner könnte zum Beispiel erklären, dass die Sprint-Review selbst nicht dazu dient, Features neu zu gestalten. Eine weitere wichtige Aufgabe ist es, das Sprintziel noch einmal zu betrachten und wie viel davon erreicht wurde. Nachdem die Begrüßung, die Grundregeln und das Sprintziel aus dem Weg geräumt sind, ist es an der Zeit, zum nächsten Punkt auf der Tagesordnung überzugehen.

Übersicht der Demo

An diesem Punkt tauchen viele Teams direkt ein und beginnen ihre Entwicklungen zu demonstrieren. Stattdessen sollte der Product Owner einen sehr kurzen Überblick darüber geben, was man zeigt und was nicht. Um zu vermeiden, dass ein Product Owner nur eine Liste von User Stories vorliest, denen die Teilnehmer nicht folgen können, besteht die Möglichkeit etwas auf dem Bildschirm oder dem verwendeten Projektor anzuzeigen. Besonders ambitionierte Product Owner können dies in einem Word-Dokument vorbereiten und es am Ende des Vortages per E-Mail an die Review-Teilnehmer senden. Dies gibt den Interessierten frühzeitig die Möglichkeit, sich auf das Event vorzubereiten und bietet dem Team die Möglichkeit weitere Stakeholder für das Event zu gewinnen.

Zu viel Zeit sollte man hierbei allerdings nicht investieren. Ziel ist es hier nicht, Feedback zu den Items zu erhalten oder darüber zu sprechen, warum ein geplantes Item nur teilweise umgesetzt wurde. Dies ist lediglich ein Inhaltsverzeichnis für den Rest des Meetings. Sollten hier bereits Diskussionen auftreten können Product Owner oder Scrum Master moderierend eingreifen. Es ist durchaus möglich, dass ein oder mehrere Teilnehmer darum bitten, eine Feature zu sehen, das das Team nicht zeigen wird. In diesem Falle sollte zeigt man das Feature mit entsprechenden Hinweisen zum Fertigstellungsgrad. Somit wird klargestellt, dass nichts verheimlicht wird, sondern man lediglich die Zeit der Stakeholder respektiert.

Präsentation neuer Funktionalitäten

Dies ist das Herzstück der Sprint Reviews. Und es ist durchaus üblich, dass dies der einzige Teil der Agenda ist, den Teams tatsächlich durchführen. Wichtig hierbei ist zu verstehen: Es geht nicht darum zu zeigen, dass die Software funktioniert, sondern dass sie nützlich und wertvoll ist. Das Team sollte versuchen zu kommunizieren, warum sie etwas entwickelt haben, welche Art von Schmerz ihr Produkt beseitigt oder wie die Arbeit von Kunden und Stakeholdern vereinfacht wird. Der Zweck der Sprint-Review ist es, Feedback einzuholen.

Es gibt keine feste Regel, wer die Demo gibt. Es ist sinnvoll, dass die Teammitglieder die spezifischen Product Backlog Elemente demonstrieren, an denen sie gearbeitet haben, während der Product Owner den Rahmen vorgibt. Viele Ansätze können funktionieren, also müssen Teams ihre eigene Lösung erarbeiten. Nicht zu unterschlagen ist ein Element der Show und Unterhaltung. Wenn Stakeholder alle 2 Wochen die Zeit investieren, um zur Demo zu kommen, sollte es angestrebt werden, die Review zu einer positiven Erfahrung für sie zu machen.

Präsentation und Diskussion anstehender Product Backlog Items

Der letzte Punkt auf der Agenda einer Sprint Review sollte eine Diskussion über die nächste Arbeit am Product Backlog sein. Da der Zweck der Sprint Review darin besteht, Feedback über die Arbeit des aktuellen Sprints zu erhalten, hat dies oft Einfluss darauf, woran das Team in späteren Sprints arbeitet. Wenn den Teilnehmern der Review beispielsweise das Aussehen der neuen Oberfläche gefallen hat, möchte der Product Owner möglicherweise die Verlagerung anderer Teile des Produkts in das neue Design beschleunigen. Oder, wenn den Teilnehmern nicht gefiel, wie ein Feature implementiert wurde, sollte man im nächsten Sprint Probleme beheben, anstatt zu den nächsten Elementen zu wechseln.

Nachdem das Team alle abgeschlossenen Product Backlog Elemente demonstriert hat, kann es wichtige Ereignisse oder Probleme besprechen, die während des Sprints aufgetreten sind. Der Product Owner beginnt diese Diskussion, indem er die nächsten möglichen Punkte aus dem Product Backlog präsentiert. Diese Diskussion kann der Scrum Master moderierrn. Dann bittet er die Teilnehmer um Kommentare zu den vorgeschlagenen nächsten Punkten. Er sollte jedoch keine Priorisierungsentscheidungen während der Sprint-Review auf der Grundlage dieser Kommentare treffen.

Abschluss der Review

Der Product Owner beendet die Veranstaltung, indem er sich bei allen für die Teilnahme bedankt. Er sollte auch erwägen, dem Team insgesamt für die Arbeit des Sprints zu danken. Er kann auch ein oder zwei Teammitglieder loben, die während des Sprints außergewöhnlich gute Leistungen gezeigt haben.

Weiterlesen? Sprint Review! Scrum Basics!