Sprint Review: Wie läuft eine Review in Scrum & Agile ab?

Die offensichtlichste Aktivität in einem Sprint Review Meeting ist die Demonstration von Funktionalität, die im vorhergehenden Sprint gebaut wurde. Ein gutes Sprint Review ist jedoch mehr als eine reine Demonstration. Schauen wir uns gemeinsam eine Agenda für ein Review Meeting an.

Die richtigen Voraussetzungen für das Review schaffen

Der Product Owner beginnt das Sprint Review Meeting, indem er alle Teilnehmer willkommen heißt. Es reicht schon völlig, wenn er etwas sagt wie: „Danke, dass ihr alle hier seid.”

Wenn die Anwesenden sich untereinander nicht kennen, kann der Product Owner sie bitten, sich kurz vorzustellen. Zu Anfang einer neuen Produktentwicklungsinitiative ist eine Vorstellungsrunde grundsätzlich eine gute Idee. Der Product Owner weiß zwar, dass Joe vom Marketing Joe vom Marketing ist; die Teammitglieder wissen das aber vielleicht nicht.

Außerdem ist es sinnvoll, dass sich alle Teilnehmer kurz vorstellen, wenn gelegentlich neue Teilnehmer zu den Sprint Reviews hinzukommen. Eventuell kommt Joe vom Marketing nämlich nur zu den Sprint Reviews der beiden Sprints, in denen das Team an marketingbezogenen Features gearbeitet hat.

Das Vorstellen sollte wirklich kurz und knapp gehalten werden. „Hi, ich bin Mike und ich bin Entwickler. Ich habe an den Einkaufswagen-Features gearbeitet”, ist fast schon zu viel. „Hi, ich bin Mike und ich bin Entwickler”, würde in den meisten Fällen schon ausreichen. Sobald ein Team allerdings eine gewisse Größe erreicht hat, kann es für die Stakeholder durchaus hilfreich sein, kurz etwas darüber zu erfahren, woran jeder Einzelne gearbeitet hat.

Nach der Begrüßung und der ggf. benötigten Vorstellungsrunde am Anfang kann der Product Owner noch einige Regeln aufstellen bzw. die Erwartungen für das Sprint Review ankündigen. Beispielsweise finden es einige Product Owner wichtig, darauf hinzuweisen, auch im Sprint Review immer freundlich zu bleiben. Wenn also jemandem nicht gefällt, wie ein Feature implementiert wurde, darf das natürlich gerne gesagt werden; man sollte die Implementierung jedoch nicht „bescheuert” nennen. Ja, natürlich wissen wir alle solche Dinge ohnehin, aber manchmal muss man nochmal daran erinnert werden.

Abhängig von der Anzahl der Teilnehmer und vielen anderen Faktoren kann der Product Owner den Anwesenden auch erklären, dass im Review zwar nach Feedback zu den bisher gebauten Features gesucht wird, dies aber nicht Zeit und Ort dafür ist, Features komplett neu zu designen.

Sobald man mit dem Intro und den Regeln für das Review fertig ist, ist es an der Zeit, zum nächsten Punkt der Tagesordnung zu kommen.

Was wird in einer Review demonstriert - und was nicht?

An diesem Punkt fangen viele Teams direkt mit der Demonstration an. Ich empfehle, dass der Product Owner erst einmal eine kurze Übersicht darüber gibt, was demonstriert werden soll und was nicht.

Um zu vermeiden, dass der Product Owner lediglich eine Liste von Items vorliest, der die Teilnehmer nicht folgen können, sollte dies für alle sichtbar auf einem Monitor oder Projektor gezeigt werden. Oder man druckt die Liste vorab aus für diejenigen, die evtl. eine Kopie davon haben möchten.

Ich persönlich schicke diese Information gerne am Abend vor dem Meeting als Word Dokument in einer E-Mail an alle potenziellen Teilnehmer des Sprint Review Meetings. Das bietet den Leuten die Chance, schon vorab zu sehen, was demonstriert werden soll. Aufgrund dessen kann dann jeder für sich entscheiden, ob es sich für ihn/sie lohnt, am Sprint Review teilzunehmen.

Die folgende Tabelle zeigt die Informationen, die meines Erachtens für jedes Product Backlog Item relevant sind. Ich würde vorschlagen, die Items in der Reihenfolge aufzulisten, in der sie auch demonstriert werden. Das kann man jedoch nach Bedarf auch noch spontan ändern.

Der erste Punkt in der Tabelle ist eine Beschreibung des jeweiligen Items. Dort wird eine User Story oder eine andere Beschreibung eingefügt. Als nächstes kommt die Größe der Items – meist in Story Points. Danach kommt der Status der Items. Hauptsächlich geht es darum, ob sie fertiggestellt sind oder nicht. Aber alles andere, was in der Hinsicht wichtig erscheint, kann dort auch hinzugefügt werden. Die letzte Spalte gibt an, ob das jeweilige Item demonstriert werden wird oder nicht.

Sie fragen sich vielleicht, warum überhaupt Items auf der Liste stehen sollen, die gar nicht demonstriert werden sollen. In der obigen Tabelle habe ich einige Beispiele eingefügt. Ganz offensichtlich kann das Item, das zwar in den Sprint aufgenommen aber dann wieder fallen gelassen wurde, nicht demonstriert werden. Außerdem habe ich ein Bug-Fix aufgelistet, bei dem es nur um ein Update für ein Zeichen auf einem Screen geht – auch dieses Item ist nicht für die Demonstration vorgesehen.

Es ist gut möglich, dass einer oder mehrere der Teilnehmer nach einem Item fragen, dass eigentlich nicht für die Demo vorgesehen war. Sollte das passieren, können Sie dieses Item ruhig zusammen mit den anderen Items vorstellen. Es geht nicht darum, zu vermeiden, dass gewisse Items gezeigt werden, sondern darum, respektvoll mit der Zeit der Leute umzugehen, indem man ihnen keine Items zeigt, zu denen man kein Feedback benötigt.

In der Beispieltabelle habe ich ein Product Backlog Item aufgeführt, das im Laufe des Sprints hinzugefügt wurde. Ich halte es für sinnvoll, dass man erkennen kann, welche Items von Anfang an für den Sprint eingeplant waren und welche während des Sprints hinzugefügt wurden. Wenn es häufiger vorkommen sollte, dass Items im Laufe des Sprints hinzukommen, kann man darüber nachdenken, eine Spalte zu der Tabelle hinzuzufügen und dort zu vermerken, ob die Items geplant waren oder nachträglich hinzugefügt wurden.

Zusätzlich kann man auch ganz rechts eine Spalte einfügen, die angibt, ob die Items von den Teilnehmern des Review Meetings akzeptiert wurden, bereit für ein Release sind o.ä. Das ist besonders sinnvoll, wenn diese Entscheidungen ein offizieller Teil des Sprint Reviews sind.

Versuchen Sie, nicht zu viel Zeit für diesen Teil der Agenda aufzuwenden. Das Ziel hier ist nicht, Feedback zu den Items zu bekommen oder darüber zu sprechen, warum ein geplantes Item nur zum Teil implementiert wurde. Diese Liste dient lediglich dazu, die Inhalte des Meetings darzustellen. Nachdem der Product Owner diese Liste vorgestellt hat, geht es zum Hauptteil des Sprint Reviews: der Demonstration.

Neue Funktionalitäten demonstrieren

Dies ist das Herz eines jeden Sprint Review Meetings. Wenn Sie bereits Sprint Reviews durchführen ist es auch gut möglich, dass dies der einzige Teil der Agenda ist, den Sie tatsächlich durchführen.

In diesem Teil des Sprint Reviews gehen Sie nach und nach durch die Liste der Items, die Sie den Anwesenden zuvor gezeigt haben. Denken Sie bitte daran, dass es der Sinn und Zweck eines Sprint Review Meetings ist, Feedback zu erhalten.

Es gibt keine feste Regelung, wer die Demo machen sollte. In einigen Fällen wird der Product Owner das übernehmen. Das würde ich immer vorschlagen, wenn besonders schwierige Stakeholder am Review teilnehmen. In anderen Fällen demonstrieren die jeweiligen Teammitglieder die Items, an denen sie gearbeitet haben, selbst. Fast jede Variante ist hier erlaubt. Experimentieren Sie einfach etwas damit und finden Sie heraus, was für Ihr Team am besten funktioniert.

Die wichtigsten Punkte besprechen

Wenn alle fertiggestellten Product Backlog Items demonstriert wurden, werden die Hauptereignisse oder Hauptprobleme dieses Sprints besprochen.

Die Diskussion kann entweder vom Scrum Master oder vom Product Owner moderiert werden. Meiner Erfahrung nach funktionieren beide Modelle gleich gut. Ich persönlich habe jedoch eine leichte Tendenz dazu, dass der Scrum Master diesen Teil des Meetings übernehmen sollte.

Bis zu diesem Punkt im Review wird der Product Owner viel mehr geredet haben als der Scrum Master. Daher halte ich es für einen guten Ausgleich, wenn der Scrum Master diesen Teil der Agenda moderiert. Außerdem ist dies streng genommen meist eher eine Diskussion über den Prozess als über das eigentliche Produkt. Daher fällt es ein wenig mehr in den Bereich des Scrum Masters.

Die nächsten Product Backlog Items präsentieren

Das letzte Item auf der Sprint Review Agenda sollte eine Diskussion zu den nächsten Arbeiten im Product Backlog sein. Da es der Sinn des Sprint Reviews ist, Feedback zu der Arbeit aus dem aktuellen Sprint einzuholen, werden dadurch auch oft die Arbeiten der folgenden Sprints beeinflusst.

Wenn den Stakeholdern der Look der neuen Screens beispielsweise sehr gut gefällt, möchte der Product Owner vielleicht schnell andere Bereiche des Produkts an das neue Design anpassen. Oder aber die Art und Weise wie die Features implementiert wurden, gefällt dem Stakeholder nicht so gut. Dann kann der nächste Sprint genutzt werden, um diese Punkte zu beheben statt mit den nächsten Items weiterzumachen (wie es ohne ein Sprint Review passiert wäre).

Der Product Owner beginnt die Diskussion mit der Präsentation den nächsten potenziellen Items aus dem Product Backlog. Er sagt dann vielleicht etwas in der Art: „Auf dem Bildschirm sehen Sie zehn Items, die ich für den nächsten Sprint vorgesehen hatte. Allerdings würde ich gerne noch gerne Item XY hinzufügen, welches heute aufgekommen ist. Wahrscheinlich werde ich es als Item Nr. 3 dazwischen schieben.”

Der Product Owner fragt die Teilnehmer dann nach ihrer Meinung zu dieser Liste. Jedoch sollte der Product Owner meines Erachtens keine Priorisierung während des Sprint Reviews aufgrund dieser Kommentare vornehmen. Dafür gibt es mehrere Gründe. Der Product Owner benötigt vielleicht etwas Zeit, um darüber nachzudenken, was gesagt wurde. Oder vielleicht möchte der Product Owner Einschätzungen vom Team zu den Änderungen einholen, die im Review gefordert wurden usw. Also holt der Product Owner im Sprint Review Meinungen ein und trifft die endgültigen Entscheidungen in Ruhe nach dem Meeting.

Die Review schließen

Beenden Sie das Meeting einfach, indem Sie allen für ihre Teilnahme danken. Bedenken Sie auch, ob Sie nicht dem Team als Ganzes für die Arbeit im letzten Sprint danken möchten, oder ab und zu einem oder zwei Teammitgliedern, die besonders gute Leistungen gezeigt haben. Dann erinnern Sie alle daran, wann und wo das nächste Sprint Review Meeting stattfinden wird.

Nach der Sprint Review

Auch wenn es nicht direkt zur Agenda des Sprint Reviews gehört, sollte doch sichergestellt werden, dass alle neuen Product Backlog Items auch in das Tool des Teams übertragen werden bzw. auf ein Post-It geschrieben und an das Scrum Board gehängt werden.

Werde Product Owner mit der Agile Academy

Wenn du neu in der Produktverantwortung bist, empfehlen wir dir ein Training zum Certified Scrum Product Owner. Hier lernst du, worauf es als Product Owner ankommt und du steigst tief in die Bedeutung und den Ablauf der Scrum Meetings ein.
Gleichzeitig erhältst du Einblicke in deine Aufgaben und lernst zum Beispiel, wie du ein Produktziel formulierst, dich auf das MVP konzentrierst und du eine Definition of Done mit dem Team formulierst.

Solltest du bereits Vorerfahrung und eine Zertifizierung der Scrum Alliance besitzen, kannst du dir zudem die Spezialisierungstrainings zum Advanced Scrum Product Owner oder sogar zum Certified Scrum Professional - Product Owner anschauen. Diese sind jedoch nur für dich buchbar, wenn du mindestens zwei Jahre Erfahrung als Product Owner gesammelt hast und du eine nicht länger als zwei Jahre zurückliegende Zertifizierung zum Product Owner erfolgreich abgeschlossen hast.