Sprint Review
Was ist ein Sprint Review?
Im Sprint Review reflektierten wir den aktuellen Arbeitsstand des Produktes. Das Scrum Team präsentiert die Ergebnisse und sucht daraus den Austausch mit den Stakeholdern. So gewinnen wir gemeinsam Klarheit über die weitere Ausrichtung des Produktes.
Viele Sprint Reviews werden leider als Status-Update und Abnahme-Meeting gelebt. So missverstanden wird ein Sprint Review niemals effektiv und diesem Zweck gerecht.
Weitere Infos zum
Sprint Review
4 Eigenschaften eines Sprint Reviews
Teilnehmer
Scrum Team
plus idealerweise Stakeholder
Dauer
4 Stunden Timebox
bei einem 30 Tage-Sprint, sonst kürzer
Session-Stil
Arbeitssession,
wo der Austausch im Forderung steht
Session-Ergebnis
Gemeinsame Klarheit,
weitere Ausgestaltung des Produkts
Die Wirkung effektiver Sprint Reviews
Ein gut gestaltetes Sprint Review setzt viele wichtige Impulse zur effektiven Produktentwicklung in Scrum.
- Die regelmäßige Einbindung der Stakeholder fördert Vertrauen & Verständnis
- Die übergreifende Abstimmung schafft gemeinsame Klarheit zum weiteren Vorgehen
- Richtig strukturiert, hilft es systematischer & produktiver vorzugehen
- Die Vorstellung, Einordnung & Bewertung der Entwickler, vertieft ihr Produktverständnis
- Der Eindruck aus dem Sprint Review setzt wichtige Impulse in der Retrospektive
Sprint Review Ablauf
Das nachfolgende Agenda-Template hat sich für uns in den letzten 10 Jahren als Startpunkt zum Aufbau eines effektiven Sprint Reviews bewährt. Dabei gilt es aber auch die Ausgestaltung und den Ablauf des Sprint Reviews an die jeweiligen Gegebenheiten anzupassen und es über das Feedback zu dem Event stetig weiterzuentwickeln.
Vorbereitung des Reviews
In unserem Sprint Review wollen wir im Scrum Team und mit unseren Gästen schnell in den richtigen Austausch kommen. Wir wollen ein gemeinsames Bild gewinnen, wo wir stehen. Fast noch wichtiger: wir wollen ein gemeinsames Verständnis gewinnen, wie wir das Produkt in Hinblick zu unserem Produktziel weiter ausgestalten.
Review nur mit Vorbereitung effektiv
Das funktioniert nur, wenn die Session gut vorbereitet ist. Wie wir dabei eine gute Orientierung geben, zu den zu zeigenden Inhalten hinzuführen und auch den Rahmen für die wichtigen Diskussionen geben ist hier entscheidend.
Vorbereitung sollte nicht aufwendig sein
Diese Vorbereitung sollte aber auf Dauer nicht sonderlich aufwendig sein. Anstelle jedes Sprint Review isoliert vorzubereiten, sollte ein Scrum Team seine Arbeit so strukturieren, dass es leicht ist, eine Orientierung zur Arbeit und dem Vorhaben zu geben.
PO muss vor dem Review wissen was Sache ist
Darüber hinaus ist es wichtig, dass in einem Scrum Team inkl. Product Owner bereits vor dem Sprint Review klar ist, was fertig ist und was nicht. Ansonsten entwickelt sich das Sprint Review unweigerlich zu einem öden Abnahme-Meeting mit fragwürdigem Mehrwert.
Unser Sprint Review Agenda-Template
Sowohl für unsere Gäste, wie für unser Scrum Team ist es wichtig eine Orientierung zu haben, wo wir gerade stehen und worauf wir aus dieser Orientierung in dieser Session den Schwerpunkt legen.
Wir können nicht von unseren Stakeholdern erwarten zu wissen wo wir gerade stehen. Damit sie gut folgen und sich gut einbringen können, ist es wichtig sie dazu entsprechend abzuholen.
Darüber hinaus ist diese Orientierung zu den Stakeholdern wichtig, um den Austausch in dem Termin effektiv zu framen. Viele von ihnen haben Einzelinteressen und Ansprüche an das Produkt, welche oft nur sehr bedingt miteinander vereinbar sind. Ohne passende Orientierung und Rahmen würde unsere Session sehr schnell aus gehijaked und ineffektiv.
Genauso ist es aber auch für viele Entwickler ungewohnt, ihre Arbeit am angestrebten Ziel zu orientieren und ihre Expertise proaktiv mit einzubringen. Deswegen ist für sie eine gute Orientierung zum Einstieg und wo wir hin wollen, mindestens genauso entscheidend.
Aus dieser Orientierung sollte allen klar sein, wo wir stehen und wo wir den weiteren Schwerpunkt des Sprint Reviews setzen. Dabei macht es oft keinen Sinn jede Kleinigkeit zu demonstrieren und Schwerpunkte zu setzen.
Eine gute Sprint Demo sollte einen guten Eindruck geben, wo wir stehen und den Anstoß für die richtigen Diskussionen geben.
Dabei reicht es nicht isolierte Änderungen des letzten Sprints zu präsentieren oder abzuspulen inwieweit man dort fleißig war.
Dazu sind aus unserer Sicht folgende Punkte besonders wichtig:
- Präsentation der Themen im Kontext
- Was haben wir geändert?
- Wie bettet sich dies in das Bestehende ein?
- Was haben wir hier aufbauend vor bzw. welche Möglichkeiten sehen wir hier?
- Eine Vorbereitung der Vorstellung, um durch unnötige Längen (z.B. bei Laden von Daten) den Spannungsbogen nicht zu verlieren
- Die Vorstellung eines Themas mit einer Frage abschließen, die den Austausch und Diskussion anstößt
Wenn wir nur über Funktionalitäten und Termine reden, verlieren wir zu leicht aus dem Blick wie wir verlässlich qualitativ nachhaltige Lösungen liefern.
Deswegen hat es sich für uns bewährt, Risiken und nichtfunktionale Anforderungen in einem eigenen Abschnitt zu reflektieren.
Das Ziel ist es zu wechselnden Schwerpunktthemen kompakte Eindrücke vorzustellen, um daraus einen effektiven Austausch anzustoßen und so zu diesen wichtigen Themen eine gemeinsame Klarheit zu gewinnen.
Zum inhaltlichen Abschluss eines Sprint Reviews und all der Diskussionen ergibt es Sinn nochmal das gemeinsame Bild zu konsolidieren, wie wir auf den Sprint gucken und auf das was wir vor uns sehen.
Ein wirklich effektives Sprint Review aufzubauen ist alles andere als trivial. Deswegen hat es sich bewährt kurz zum Abschluss ein Stimmungsbild zu diesem Termin einzuholen und was wir für die effektive Gestaltung des kommenden Sprint Reviews daraus mitnehmen.
Alternative Sprint Review Abläufe
- Mike Cohn gibt hier eine konkrete Agenda, die sich für ihn im Sprint Review bewährt hat.
- Auf der Seite von Mural findet sich dieser Ablauf für ein Review incl. Mural-Board als Template
- In diesem Artikel beschreibt Erik Weber bei Scrum.org, dass man ein Sprint Review auch in einem Messe Setup organisieren kann
3 Sprint Review Beispiele
2020 hat Ralf Kruse eine #remotescrum-Session moderiert in der Praktiker ihre Erfahrungen in der Durchführung eines Sprint Reviews vorstellen.
Wir hoffen diese Beispiele aus der Praxis geben euch einige Einblicke, für die Gestaltung effektiver Sprint Reviews.
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
Sprint Review im Zusammenspiel mit Scrum
Ein Sprint Review findet nicht im luftleeren-Raum statt. Deswegen ist es so wichtig zu verstehen, wie Scrum im Zusammenspiel funktioniert und wie wir an anderen Stellen für ein wirklich gut funktionierendes Sprint Review die Veraussetzungen schaffen.
Backlog Refinement legt den Grundstein für ein effektives Sprint Review
Wenn das Product Backlog aus isolierten kleinteiligen Funktionalitäten besteht, die beschreibungsgetreu geliefert werden, dann passt dies weder zu Scrum noch zu der Gestaltung eines effektiven Sprint Reviews.
Letztlich entsteht aus einem so gestalteten Product Backlog die Erwartung, dass im Sprint Review sich primär auf die Abnahme nach den vorher formulierten Backlog-Items konzentriert wird. Da aber wie oben beschrieben ein gutes Sprint Review eine Inspect & Adapt Session ist, verdrängt die Abnahme so den eigentlichen Zweck des Sprint Reviews.
Um ein effektives Sprint Review zu gestalten, brauchen wir idealerweise einen Ausblick zum Produkt in Hinblick auf das Produktziel. So können wir dann die Eindrücke vom aktuellen Arbeitsstand als Anstoß nehmen diesen Ausblick nachzujustieren.
Darüber hinaus hilft es ungemein, im Backlog Refinement größere Items im Scrum Team früh zu Schätzen, um früh einen Eindruck zu bekommen, wie man auf diese Backlog-Items guckt. Dabei entsteht immer auch ein Bild zu Unbekannten, Unsicherheiten und Risiken, die wir dann aufgreifen können, um den Split der Backlog-Items auf das Lernen aus der Lieferung des Ergebnisses zu forcieren.
So arbeiten wir dann mehr an Backlog-Items aus deren Lieferung wir gemeinsam das Produkt weiter ausgestalten wollen, was ja quasi der Kern eines guten Sprint Reviews ist.
Im Sprint Review zeigt sich, wie gut die Entwickler den Input aus Planning & Refinement verstehen
Neben der Optimierung der Aufarbeitung von Backlog-Items bringen sich die Entwickler in Scrum aktiv in das Setzen des Sprint-Fokuses in Form des Sprint-Ziels, der eigenverantwortlichen Erarbeitung von Ergebnissen im Sprint und auch in der Bewertung & Einordnung der Ergebnisse im Sprint Review mit ein. So verhindern wir, dass aus der Einzelsicht eines POs unnötig naive Fehler passieren und können als Team effektiver gemeinsam ein Produkt entwickeln.
Für viele Entwickler ist dieser höhere Anspruch sich aktiv in die Gestaltung des Produktes über isolierte Features hinaus einzubringen ungewohnt.
In einem gut funktionieren Scrum Team liegt ein wesentlicher Teil der Orientierung, Einordung, Vorstellung und Bewertung der Ergebnisse im Sprint Review bei den Entwicklen.
Agiert hier primär der PO, solltet ihr euch fragen ob:
- Der PO mehr und besser zum Produkt kommunizieren sollte
- Wie die Entwickler mehr an den Anspruch mitdenken und gestalten zu können herangeführt werden.
Kein gutes Sprint Review ohne Entwickler die im Sprint Verantwortung übernehmen
Wir müssen uns darauf verlassen können, dass das was abgesprochen ist im Sprint Review auch fertig ist und proaktiv kommuniziert wird, wenn dies nicht der Fall ist, um sich darauf einzustellen.
Dazu brauchen wir Entwickler, die sich dieser Erwartung bewußt sind und vorausschauend, verlässlich proaktiv agieren.
Möchtest du Scrum für deine Zwecke effektiver nutzen?
So unterstützen Scrum Master Reviews
De Scrum Guide definiert für den Scrum Master nur, dass dieser dafür sorgt, dass das Sprint Review stattfindet und seinen Zweck erfüllt.
Der Scrum Master als Moderator im Sprint Review
Darüber hinaus bietet sich der Scrum Master aber grundsätzlich als Moderator des Sprint Reviews an. PO und Entwickler sind einfach stärker inhaltich eingebunden und haben es damit schwerer sich auf die Moderation und die Förderung einer effektiven Zusammenarbeit zu konzentrieren.
Darüber hinaus sollte man aufpassen, dass wir als Scrum Master nicht in die Rolle als Kümmerer und Antreiber abrutschen. Achtet deswegen bitte darauf, dass folgende Sachen nicht euer Handeln im Sprint Review als Scrum Master dominieren:
- dass ihr nicht die einzige Person seid, die das Product Backlog ausgehend von den Ergebnissen aktualisiert. Das ist ein Arbeitsmittel vom Scrum Team und wenn nur ihr es pflegt, dann werdet ihr ihnen diese Sachen auf ewig hinterhertragen.
- dass ihr nicht ohne Einbindung des Scrum Teams das Format vom Sprint Review vorgebt und ohne Mandat dies durchmoderiert. So entsteht schnell unnötige Reibung und viele bringen sich so immer weniger in den Termin ein.
- dass ihr den weiteren Umgang aus den Eindrücken von den Diskussionen bestimmt. Hierzu wollen wir die Teilnehmer aktiver in die Verantwortung nehmen und den PO dafür positionieren dies sinnvoll weiterzuführen.
Wie positioniere ich mich als effektive Unterstützung für das Sprint Review
Als Scrum Master wollen wir hier bedarfsgerecht unterstützen und wünschen uns Klarheit, wo sich die Teilnehmer des Sprint Reviews von uns Unterstützung wünschen.
Dazu bieten sich besonders zwei Wege an:
Zum Ende eines Sprint Reviews kann man sich ein sehr kompaktes Feedback zum Sprint Review abholen, um daraus Verbesserungen und Unterstützungsmöglichkeiten abzuleiten. Schließlich mag keiner schlechte Meetings und so lassen sich daraus schnell die Unterstützungswünsche ein möglichst gutes Sprint Review ableiten. Ein Weg ist das Einholen eines Stimmungsbildes zur Return on Time Invested, kurz ROTI. Eine Beschreibung dazu findest du hier.
Ergänzend dazu kann man aus Einzelgesprächen ein Stimmungsbild ermitteln, wie sich die Teilnehmer zu der Durchführung eines guten Sprint Reviews aufgestellt fühlen. Diese Eindrücke kann man dann so konsolidieren, dass man zu Beginn eines Sprint Reviews daraus gemeinsam mit den Teilnehmern ableiten kann, wo man sich wie Unterstützung im Sprint Review wünscht.
Möchtest du als Scrum Master mehr bewegen?
Wie agieren Product Owner im Review?
Für den Product Owner ist das Sprint Review ein wichtiger Punkt um Feedback zu bekommen.
Dazu agiert er aber gleichzeitig im Verbund mit seinem Scrum Team. Hier ist der PO vor allem gefragt im Product Backlog Refinement, der Sprint Vorbereitung und dem Sprint Planning die Entwickler soweit zu orientieren, dass diese im Sprint selbstsätndig agieren können und aktiv bewertend im Sprint Review sich mit ihrer Expertise einzubringen. Je besser dies klappt, desto weniger sollte der PO im Sprint Review gefragt sein, den aktuellen Stand des Produktes einzuordnen.
Wenn du also als PO der Einzige bist, der den Sprint und die gelieferten Funktionalitäten in den größeren Kontext einordnet, dann ist das ein starker Indikator für ein unzureichendes Agieren des Scrum Teams. Entweder ist deine Kommunikation zum Produkt ausbaufähig oder die Entwickler übernehmen ihre Verantwortung nur mangelhaft. Beides Themen, die man adressieren sollte.
Neben den Entwicklern zu helfen, dass Produkt wirklich gut zu verstehen und mitdenkenden zu können, hilft der PO dabei ein gutes Bild auf das Umfeld zu haben und diese Perspektive in die Vorbereitung mit einzubringen.
Im Sprint Review selbst präsentiert der PO die Ergebnisse mit dem Scrum Team und versucht insbesondere durch die Art in der das Event organisiert ist, die Stakeholder effektiv abzuholen und wie oben beschrieben die richtigen Diskussionen anzustoßen.
Besonders wichtig wird seine Rolle im Sprint Review um aus den Diskussionen eine Klarheit zu schaffen, wie die eingebrachten Perspektiven für die weitere Ausgestaltung des Produktes aufgegriffen werden.
Das kann in direkten konkreten Änderungen im Procuct Backlog resulten, kann aber einfach auch in einem informellen Ausblick münden, wie die Themen bewertet und weiter aufgegriffen werden.
Suchst du nach einem guten Einstieg in die Product Owner Rolle?
Erlebe Agilität und Scrum an 2-tägigen interaktiven Live-Online Training, um dein Verständnis der Rolle auf den nächsten Level zu heben.
Podcast-Folge zum Thema
In der Scrum meistern Podcast-Folge #28 “Sprint Review” arbeite ich die geschilderten Punkte noch mal im Zusammenspiel auf.
Hör doch mal rein 😉
.
Klicken Sie auf den unteren Button, um den Inhalt von Spotify zu laden.
Antworten auf gängige Fragen
Scrum definiert nur, dass der Scrum Master dafür sorgt, dass das Scrum Event stattfindet und seinen Zweck erfüllt. Darüber hinaus ist bewusst offen gelassen, wer das Sprint Review moderiert.
Viele sehen den Product Owner als prädestiniert an, durch das Sprint Review zu führen. Davon raten wir aber ab, da der PO stark inhaltlich involviert ist und damit zu stark für eine gute Moderation ausgelastet ist.
Üblicherweise bietet sich der Scrum Master als Moderator vom Scrum Review ähnlich, wie in den anderen Events an. Fest vorgeschrieben ist das aber nicht.
Scrum lässt ganz bewußt offen, wer zu diesem Scrum Event einlädt.
Das gibt uns die Freiheit, dass die geeigneteste Person zu dem Termin einladen kann, beispielsweise kann es sich in einer hierarchischen Organisation anbieten, dass über die Einladung durch einen Sponsor die Wichtigkeit dieses Termins bei den Gästen verdeutlicht wird. Dabei ist die gemeinsame Verantwortung zur Vorstellung des Arbeitsstandes vom Scrum Team klar geregelt und die Person, die einlädt hat darauf keinen Einfluss.
Darüber hinaus finden die Sprints in Scrum in einem festen Rhythmus statt und damit auch die Termine in einem festen Rhythmus. Dadurch kann die Einladung zu dem Termin selbst durch einen Serientermin organisiert werden und damit hält sich der Aufwand zur Einladung stark in Grenzen.
Der Fokus vom Sprint Review liegt bewusst nur auf dem Inspect & Adapt vom Produkt und nicht auf dem Review der Arbeitsweise. Dafür gibt es heute die Sprint Retrospektive.
Das war in den Anfängen von Scrum anders, da wurde sowohl Produkt als auch Arbeitsweise im Sprint Review reflektiert. Allerdings verwob sich so schnell die Reflexion des Produktes mit der Rechtfertigung warum dies in der aktuellen Aufstellung der Arbeitsweise schwierig ist, was weder der Reflexion von Produkt noch von der Arbeitsweise dienlich ist.
Darüber hinaus wurde deutlich, dass ein Sprint Review mit Gästen zwar sehr hilfreich für die Reflexion des Produktes, aber eben auch kein Safe-Space ist, um im Team offen die wirklichen Probleme adressieren zu können.
Deswegen wurde ab 2003 die Sprint Retrospektive ein fester Bestandteil von Scrum.
In diesem Zusammenhang gibt das Buch Project Retrospectives: A Handbook for Team Reviews von Norman Kerth aus 2001 einen guten Einblick, woraus sich die Einbindung von Retrospektiven in Scrum motiviert.
Durch die Einführung der Sprint Retrospektive hat das Sprint Review an Profil gewonnen und ist klarer auf die Reflexion des Produktes zugeschnitten.
Aus unserer Erfahrung wird sowohl das Sprint Review, wie die Sprint Retrospektive effektiver, wenn man die Diskussionen zu Vorgehen und Arbeitsweise im Sprint Review auf ein Minimum reduziert ist.
Zum einen verwässert dies oft den fokussierten Austausch zum Zustand des Produktes, was den Gehalt der Session gerade für Gäste reduziert, zum anderen schwächt das umfassende Erklären und Rechtfertigen im Sprint Review schnell auch das Aufgreifen von Verbesserungsthemen in der Retrospektive ab. Schließlich hat man sich ja schon im Sprint Review erklärt.
Beide Scrum Events sind wichtig und ergänzen sich sinnvoll.
-> Wenn du mehr über Scurm erfahren möchtest …
Üblicherweise ist die Sprint Demo ein zentraler Bestandteil von einem Sprint Review. Ein Sprint Review geht als Inspect & Adapt Session über eine bloße Vorstellung und Diskussion hinaus.
In diesem Sinne sollte ein Sprint Review einen guten Eindruck aus dem Austauch zum aktuellen Arbeitsstand geben und wie man daraus gedenkt das Produkt in Hinblick auf das Produktziel weiter auszugestalten.
