Das Sprint Review ist das vorletzte Event im agilen Framework Scrum. Zuvor haben bereits die Sprint Planung und das Daily Scrum stattgefunden. Nach dem Sprint Review folgt die Sprint Retrospektive.
Das Sprint Review bietet die Möglichkeit das Produkt zu inspizieren und anzupassen. Dabei sollte das Sprint Review nicht als einfache Präsentation verstanden werden, sondern als ein Lernevent, in dem das Feedback der Stakeholder maximiert wird. Damit der Kundenwert noch besser verstanden wird, und klar ist, was die einzelnen Stakeholder wünschen.
Übersicht über das Sprint Review
Das Sprint Review in Scrum ist das Meeting, in dem das Team vorstellt, was es in diesem Sprint geleistet hat. Es ist damit eines der Scrum Events, welches das agile Prinzip der Transparenz sehr stark unterstützt. Ziel des Sprint Reviews ist es, ein funktionierendes Produktinkrement den Stakeholdern, Endnutzern und anderen Interessenten erlebbar vorzustellen. Das Sprint Review ist allerdings mehr, es ist ein Lernevent und sollte nicht als "einfache Demo" verkommen.
Scrum Guide
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
Im folgenden Video zu Scrum findet das Sprint Review Meeting seinen Platz. Schaue es dir gleich einmal im Explainer Style an.
Grundlagen zum Sprint Review
Das Sprint Review folgt einem recht einfachen Ablauf. Es ist wichtig, dass gerade bei inhaltlichen Diskussionspunkten nicht abgeschweift wird. Der Scrum Master moderiert hier, wenn nötig. Die Einladung zum Sprint Review kann gerne direkt vom Product Owner kommen, ist aber keine Pflicht.
Durch die Wiederholung deiner Sprints (Iterationen) betrachtest du in jedem Sprint Review ein Inkrement, welches auf dem vorherigen aufsetzt.
Input, Ablauf und Output des Sprint Reviews
Thema | Inhalt |
|---|---|
Input für das Sprint Review | |
Ablauf innerhalb des Sprint Reviews | |
Output der Sprint Planung | |
Dauer |
Dysfunktion: Wir haben aber nichts zu zeigen!
Ein häufiges Argument in Sprint Reviews ist "wir haben nichts zu zeigen". Wenn Sie dieses Aussage auch hören, dann ist die erste Frage nach dem Warum. Oft liegt das Problem darin begraben, dass die Teams vorher sequentiell gearbeitet haben und nun dieses sequentielles Vorhaben nur 1:1 auf die kürzen Sprints nur aufgeteilt wird. Hier sollten Sie einen Blick auf die Art der Product Backlog Items werfen und auch einmal auf das Produkt einen Blick zu werfen - macht das Sinn, dieses tatsächlich agil zu entwickeln?
Dysfunktion: Es werden immer alle Tickets durchgegangen
Das Sprint Review ist ein informelles Meeting und kein Statusmeeting. Hier soll erreicht werden, dass Sie Feedback bekommen und Zusammenarbeit fördern. Der Product Owner ist zwar die finale Instanz, die über Abnahme entscheidet, aber das muss nicht am Ende und nur im Sprint Review entschieden werden. Zudem ist es absolut in Ordnung sich auf die wichtigsten Themen zu konzentrieren, die (den Stakeholdern) gezeigt werden.
Eine gute Agenda für das Sprint Review erstellen
Ein Sprint Review soll ein Erlebnis sein und die Teilnehmer begeistern und ein gutes Gefühl geben. Beim Sprint Review soll Feedback erzeugt und nächste Schritte bestimmt werden. Und dazu müssen Sie im Sprint Review etwas zeigen können, was auch wert ist zu zeigen: Mehrwert für die Teilnehmer. Über die Anzahl deiner Sprints kann dir der Scrum Master helfen, die Agenda Stück für Stück zu verbessern. Das ganze Team kann und darf hier natürlich helfen.
Im Sprint Review geht es um das Produkt, also sollte der Product Owner sich auch nicht die Gelegenheit nehmen lassen, zu diesem Termin eine kurze Begrüßung aussprechen, die Menschen willkommen heißen und das Event zu eröffnen. Alles was nicht direkt zum Produkt gehört, wird im Vorfeld kurz gefasst.
Haben wir in diesem Sprint das Sprint Ziel erreicht? Mit der Beantwortung dieser Frage haben Sie schon wichtiges geschafft: Den Fokus zu setzen und gleich den Eindruck zu geben, wie erfolgreich der Sprint war. Wenn das Sprint Ziel "Live setzen der neuen SAP Eingabemaske" war und Sie diese Frage mit ja beantworten können, dann gibt das dem Event eine gute Richtung.
Jetzt werden Product Backlog Items vorgestellt. Dabei gilt: Man muss nicht immer alles vorstellen! Oft reicht es, wenn die Teilnehmer wissen, das Sprint Ziel ist erreicht und die wichtigstens Product Backlog Items, die auf das Thema einzahlen, erlebbar sind. Dabei stellt das Entwicklungsteam die PBI bitte immer selbst vor. Zur Orientierung kann der Product Owner die zu zeigenden PBIs im Vorfeld an die Teilnehmenden schicken, dann ist die Erwartungshaltung klar. Es kann sich zum Beispiel im Daily Scrum herausstellen, was konkret gezeigt werden soll, aber auch zu jedem anderen Zeitpunkt. Es sollte nur vorher klar sein.
Nun wissen Sie, ob das Sprint Ziel erreicht worden ist, welche Product Backlog Items enthalten sind und jetzt kann das Entwicklungsteam damit beginnen, tatsächlich etwas zu demonstrieren. Das ist der Hauptteil des Sprint Reviews und sollte allen Beteiligten eine Menge an Möglichkeiten für das Erlebnis und das Feedback einräumen. Es gehört zur Wertschätzung und zum Zeigen der Kompetenz, dass das Entwicklungsteam direkt und selbst zeigt. Gibt es schwierige Stakeholder kann und sollte der Product Owner das entsprechende Geschick besitzen, das Entwicklungsteams zu unterstützen, wenn das nötig ist. Denken Sie daran, dass der Product mehr im Bereich "was" (Produkteigenschaften) die Hoheit haben sollte, das Entwicklungsteam im "wie" (konkret umgesetzte Funktionalität).
In einem weiteren Teil der Sprint Review Agenda wird kurz über die Erlebnisse und möglicherweise auch Probleme gesprochen, denen das Team bei der Produktentwicklung begegnet ist. Dabei liegt der Fokus nicht auf der Reflexion des eigenen Prozesses, als viel mehr auf dem des Produktes. Der Prozess wird mit den Teilnehmer in der Sprint Retrospektive besprochen. Zudem kann der Product Owner noch einmal den Stand und Fortschritt aus Produktsicht, Releases und voraussichtlicher Prognose für Termine auf Basis der empirisch ermittelten Velocity zeigen.
Wir gehen auf das Ende des Sprint Reviews zu. Dort geht es darum, dass der Product Owner die nächsten Product Backlog Items vorstellt, die wahrscheinlich umgesetzt werden. Das passiert meistens auf Basis des Sprint Reviews, der Erlebnisse und der Erkenntnisse. Wenn Ihr Produkt weniger starke Schwankungen auf dem Markt besitzt, dann kann es sein, dass dieser Abschnitt kurz ausfällt oder nur selten adressiert wird. Am Ende sollte auf jeden Fall klar sein, welches die nächsten wahrscheinlichen Product Backlog Items sind.
Wie viel Zeit benötigt das Sprint Review?
Der Scrum Guide gibt eine Timebox von vier Stunden für einen einmonatigen Sprint für das Sprint Review an. In meinem Artikel zum Meeting Overhead beleuchte ich die Zeiten vom Sprint Review noch einmal genauer. Dein Scrum Master hilft dir hier Klarheit zu schaffen.
Je nach Team und ggf. einer Scrum Skalierung kann der Bedarf nach mehr Zeit für ein Sprint Review steigen. Gerade wenn Teams sehr motiviert sind und erledigte Arbeit gerne zeigen möchten. Was bei einem Team meist recht problemlos funktioniert, kann im größeren Kontext schwierig werden. Gerade wenn du mehrere Teams hast (die alle an einem Produkt arbeiten), sollten sich die Teams so abstimmen, dass (z.B. durch Marktstände oder ähnliches) die Feedbackmöglichkeit für die Stakeholder maximiert wird.
Abnahme von Product Backlog Items
Gerade wenn Teams immer viel zeigen wollen, aber natürlich auch sonst, gilt die Regel, dass Product Backlog Items jederzeit vom Product Owner "abgenommen" werden. Wenn du so möchtest, ist das Sprint Review natürlich nur der letztenmögliche Zeitpunkt, bei dem das geschehen kann. Das trägt ein gewisses Risiko, es lohnt sich deshalb fertige Product Backlog Items schon vorher abzunehmen. Wenn das Entwicklungsteam etwas fertiggestellt hat, kann es zum Product Owner gehen und darum bitten.
Der Product Owner nimmt die Product Backlog Items in der Regel immer ab, wenn die Definition of Done erfüllt ist und die Akzeptanzkriterien ebenso Anwendung gefunden haben. Das ist ein Entwicklungsprozess, spielt sich aber mit der Teamreife meistens ein.
Über die Sprints hinweg sollte die Abnahme von mal zu mal besser werden. Wenn du entdeckst, dann auch noch mehreren Sprints immer noch keine Verbesserung eingetreten ist, dann schaue doch mal nach der Größe deiner Product Backlog Items und ebenso nach der Art deiner Arbeit.
Dysfunktion: Alles was wir nicht schaffen, ziehen wir immer in den nächsten Sprint!
Häufig findet man das folgende Verhalten zwischen dem Sprint Review und der Sprint Planung. Zum einen wird im aktuellen Sprint oft nicht alles geschafft, zum anderen wir immer alles in den nächsten Sprint überführt. Kommt Ihnen das bekannt vor? In solch einer Situation sollten Sie sich einmal fragen, wie volatil ihr Umfeld ist. Dann lohnt sich auch die Frage, ob diese Situation jemanden stört. Wenn ja, wen?
Lerne im Sprint Review
Im Sprint Review kannst du sehr viel über dein Produkt lernen. Klar, dazu musst du natürlich ein Produkt entwickeln und auch entsprechend Scrum korrekt einsetzen 🙂
Lerne die Benutzung des Produktes durch deine Kunden kennen
Lernen Sie neue Formen des Sprint Reviews
Natürlich sind eingeschwungene Agenden gut für die Planung. Aber ab und an wirken sie auch mal dröge. Wie kannst du neuen Wind in das Sprint Review bringen? Wenn es um's Lernen geht, dann ist es wichtig, dass du auch maximal lernen kannst. Dazu solltest du (wenig überraschend) die folgenden Dinge vermeiden.
Lernen funktioniert also dann immer gut, wenn du im Sprint Review für das Format auch mal etwas ausprobierst, was ein gutes Lernpotential birgt. Das muss sich natürlich nicht nur auf das Format beschränken.
Einige Möglichkeiten und Fragen:
