Sprint Review

Inhaltsverzeichnis: Definition – Teilnehmer – Event – Ablauf – Präsentation der Ergebnisse – Timeboxing – Vorteile – Tipps und Tricks – Download – Hinweise

Wissen kompakt: Das Sprint Review ist ein Treffen von Entwicklern, Scrum Master und Product Owner am Ende eines Sprints zur Präsentation der Entwicklungsergebnisse und Festlegung zukünftiger Anpassungen.

Sprint Review Definition

Das Sprint Review ist ein Treffen am Ende eines Sprints zur Begutachtung der erledigten Arbeit in Bezug auf das gesteckte Sprint-Ziel. Der Scrum Guide definiert: “The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next.”

Idealerweise hat das Team jedes Sprint Backlog Item fertiggestellt, wichtiger ist aber die Erreichung des Sprint-Ziels, das im Sprint Planning gemeinsam vereinbart wurde. Präsentiert werden beim Review lediglich die Items, die entsprechend der Definition of Done auch tatsächlich fertiggestellt wurden.

Sprint Review als regelmäßiges Treffen zur Begutachtung des Inkrements

Teilnehmer am Sprint Review

Am Sprint Review nehmen das gesamte Scrum Team – also die Entwickler, der Scrum Master und der Product Owner – und idealerweise auch Stakeholder – also bspw. Anwender, Manager, Vertreter aus Bereichen wie Marketing, Vertrieb oder IT – teil. Natürlich adressiert das Sprint Review nicht alle Stakeholder; Wettbewerber sind auch von den Ergebnissen betroffen, sie werden aber nicht dazu beitragen wollen, das Produkt eines Konkurrenten zu verbessern.

Im Fokus des Meetings steht in der Praxis vor allem der Austausch der Entwickler mit dem Product Owner als Stellvertreter der Stakeholder. Kann dieser nicht alle fachlichen Aspekte abdecken, sollte der Auftraggeber am Sprint Review teilnehmen oder einen entsprechenden Stellvertreter schicken. Ist dies nicht möglich, verschiebt sich die Abnahme entsprechender User Storys. Bei komplexen Storys sollte der Auftraggeber schon vor dem eigentlichen Review eingebunden werden, denn sonst könnte die Abnahme zu umfangreich werden und scheitern.

Sprint Review als Scrum Event

Scrum definiert verschiedene Events, die einmalig oder mehrfach durchgeführt werden. Dazu gehören neben dem Sprint Review das Sprint Planning, der Sprint, dasDaily Scrum und die Retrospektive. Auch das Backlog Refinement wird als kontinuierliche Aufgabe durchgeführt; es handelt sich aber nicht explizit um ein Scrum Event.

Alleine die Anzahl der Events – manchmal auch als Rituale, Zeremonien oder Meetings bezeichnet – lässt die Bedeutung von Kommunikation im agilen Kontext erkennen. Dabei ist kein Event wichtiger als ein anderes, denn jedes verfolgt eigene Ziele und einen konkreten Sinn. Der Sinn des Sprint Reviews liegt im Feedback der Stakeholder – Meinungen, Kritik, Lob und Verbesserungsvorschläge – das in die weitere Entwicklung einfließt.

Ablauf im Sprint Review

Nach einer kurzen Begrüßung – ein Unfreezing ist an sich unnötig und geht gegen die vereinbarte Timebox – durch den Product Owner und einer kurzen Vorstellung der Teilnehmer, sofern diese sich nicht kennen, folgt die Erläuterung der Regeln. Eine goldene Regel wie bei der Sprint Retrospektive ist besonders nützlich.

Bevor das Team mit der Präsentation der realisierten User Storys beginnt, sollte der Product Owner eine Liste präsentierten und gegebenenfalls verteilen, aus der ersichtlich wird, welche Items umgesetzt wurden und demonstriert werden und welche nicht. Diese Liste sollte im Vorfeld zwischen dem Product Owner und den Entwicklern abgestimmt werden, denn aus ihr ergibt sich auch die spätere Präsentationsreihenfolge der umgesetzten Items. In manchen Organisationen wird diese Liste bereits bei der Einladung zum Sprint Review verschickt, denn so fällt es Besuchern aus Marketing oder Vertrieb leichter zu entscheiden, ob eine Teilnahme für sie sinnvoll ist.

Das Herzstück des Sprint Reviews ist die Präsentation der neuen Funktionalität, idealerweise durch die Entwickler selbst. Hier wird das Feedback der Teilnehmer abgefragt und die User Storys werden bestenfalls abgenommen, gegebenenfalls aber eben auch nicht abgenommen. Bevor es zu einer Diskussion über die demnächst anstehenden Backlog Items kommt, kann der Scrum Master noch die größten Herausforderungen des Sprints erläutern. Meist beziehen sich diese Punkte eher auf den Prozess als auf die Umsetzung der Anforderungen. Das Sprint Review sollte mit einem Dank an die Entwickler und Präsentatoren und dem Termin für das nächste Sprint Review enden.

Die regelmäßige Präsentation der Ergebnisse

Es gibt gute Gründe, warum Features einer Software live präsentiert werden, bevor die Software vollständig entwickelt ist. Auch wenn es Manager gibt, die für solche Präsentationen wenig Zeit investieren wollen, so ist es auf Dauer die einzige Möglichkeit, einen eigenen Blick auf den Fortschritt einer Entwicklung zu werfen.

Fortschrittsmeldungen per Mail oder Informationen zwischen Tür und Angel können funktionieren, es ist aber deutlich wahrscheinlicher, dass am Ende Ergebnisse entstehen, die für den einen oder anderen Verantwortlichen überraschend sind. Durch die regelmäßige Präsentation der Ergebnisse erhalten das Management und auch wichtige andere Stakeholder die Möglichkeit, eigene Eindrücke zu gewinnen, Fehlentwicklungen zu erkennen, Feedback zu geben oder Wünsche und Ideen zu äußern.

Das Sprint Review bietet eine hervorragende Möglichkeit der Steuerung, es ist eine Art Entwicklungs- und Projektcontrolling in Echtzeit. Aussagen wie “Wir sind im Plan” können nun selbst überprüft werden – alles was dazu benötigt wird, ist einmal im Monat ein Investment von 4 Stunden oder weniger. Darüber hinaus transportiert auch die Teilnahme der Stakeholder eine Aussage in Richtung der Entwickler: “Wir interessieren uns für eure Arbeit und eure Ergebnisse”. Die Alternative könnte als Ignoranz wahrgenommen werden und sogar zu Demotivation führen.

Timeboxing im Sprint Review

Kommunikation und Feedback sind in Scrum sehr wichtig. Damit diese Kommunikation in geordneten Bahnen verläuft und nicht zu viel Aufwand durch die verschiedenen Meetings verursacht wird, empfiehlt sich der Einsatz einer Timebox. Der Scrum Guide empfiehlt für einmonatige Sprints eine Timebox von 4 Stunden oder weniger für ein Review, bei einem dreiwöchigen Sprint von 3 Stunden oder weniger, usw.

Damit die vereinbarte Timebox eingehalten werden kann, ist es notwendig, sinnvoll und strukturiert miteinander zu kommunizieren. Es macht viel Sinn, zu Beginn des Reviews allen Beteiligten den Ablauf zu beschreiben, selbst wenn die meisten oder gar alle Teilnehmer bereits früher an Sprint Reviews teilgenommen haben. Durch die Erläuterung des Sprint-Ziels, die Betrachtung des Fortschritts in Richtung Product Goal bzw. Produkt-Ziel und die Nennung der Timebox erhalten die Beteiligten darüber hinaus weitere Orientierungspunkte.

Nimmt der Auftraggeber an dem Treffen teil, kann es zu umfangreichen Diskussionen über die Intention von Anforderungen und den Entwurf von neuen Features kommen. Auch hier gilt es, die Timebox im Auge zu behalten. Evtl. ergeben separate Treffen mit einer geringeren Anzahl von Teilnehmern mehr Sinn und reduzieren den Aufwand.

Vorteile von Sprint Reviews

Die Durchführung eines Sprint Reviews am Ende eines Sprints bietet verschiedene Vorteile:

Beim Sprint Review wird sichtbar, was bereits erarbeitet wurde. Da nur realisierte User Storys und deren Umsetzung live im Produkt präsentiert werden dürfen, ist der Fortschritt der Entwicklung für alle Beteiligten direkt ersichtlich.
Zwischen den Entwicklern und den Stakeholdern gibt es direktes Feedback und somit Kritik, Lob oder Verbesserungsvorschläge. Diese können gegebenenfalls vom Product Owner für den nächsten Sprint priorisiert werden.
Die Stakeholder erhalten lebendige Information über die Entwicklung anstelle anonymer Berichte. Somit ist die Auseinandersetzung mit den Ergebnissen deutlich leichter.
Der Vorbereitungsaufwand ist für Entwickler gering, denn nur fertige Lösungen werden präsentiert. PowerPoint-Präsentationen oder ähnliche Medien sollten im Review vermieden werden.
Die Identifikation des Teams mit eigenen Arbeitsergebnissen steigt.
Ideen für weitere Funktionalitäten lassen sich gemeinsam entwickeln.

Tipps und Tricks beim Sprint Review

Es gibt eine Reihe von Tipps und Tricks, die zum Gelingen eines Sprint Reviews beitragen können:

Die Anzahl der Teilnehmer kann sehr groß werden, daher sind eine gute Moderation, klare Regeln und Abläufe, sowie die konsequente Ausrichtung an der vereinbarten Timebox sehr wichtig.
Meist ist der Product Owner auch der Moderator des Scrum Events. Er hat also zwei Hüte auf, die er auf jeden Fall trennen muss. Er darf natürlich Feedback geben, aber er sollte sich bspw. bei der direkten Einplanung von neuen User Storys aufgrund des gelieferten Feedbacks zurückhalten.
Die Teilnahme von wichtigen Stakeholdern ist wesentlich, denn durch ihr Feedback wird der tatsächliche Wert der Realisierung eindeutig verifiziert.
Geringe Präsentationsfähigkeiten der Entwickler können bei Stakeholdern zu mangelnder Akzeptanz führen. Hier sollte eine bewusste Entscheidung getroffen werden, ob denn eine interne Regel – das Feature wird von dem Entwickler präsentiert, der es umgesetzt hat – beibehalten oder im besonderen Fall alternativ gehandhabt wird.
Die Freigabe von realisierten User Storys ist wichtig, aber das Feedback ist viel wichtiger. Aus dem Feedback ergeben sich die Freigaben. Verkommt das Sprint Review zu einem reinen Freigabe-Event wird der eigentliche Sinn verfehlt.