Die Sprint Review ist der vorletzte Scrum Event eines Sprints. Wie das Sprint Planning, das Daily Scrum und die Sprint Retrospektive ist sie ein Workshop, der Überprüfung & Anpassung (Inspection & Adaption) ermöglicht. In diesem Artikel zeige ich Dir, was der Sinn & Zweck einer Sprint Review ist und worauf Du gemeinsam mit Deinem Team achten solltest, um sie erfolgreich einzusetzen.
Sinn & Zweck der Sprint Review
Der Zweck der Sprint Review wird explizit im Scrum Guide formuliert:
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations.
Wie Du sehen kannst, geht es in der Sprint Review (wie in den anderen Scrum Events auch) sowohl um Überprüfung als auch um Anpassung. Gerade Letzteres wird jedoch häufig ignoriert, sodass die Sprint Review zu einem reinen “Sprint-Abnahmetermin” verkommt. Das ist allerdings gar nicht Sinn und Zweck der Veranstaltung.
Eine gute und erfolgreiche Sprint Review soll zu einer Anpassung Deines Product Backlogs führen, sofern die entstehenden Erkenntnisse das notwendig machen. Es geht also nicht darum, dass Du als Product Owner die Arbeit “Deiner” Entwickler abnimmst.
Elemente einer guten Sprint Review
Um Eure Sprint Review als erfolgreichen Workshop zu gestalten und das oben angesprochene Problem zu vermeiden, solltet Ihr in Eurem Scrum Team auf einige wichtige Elemente achten.
Teilnahme wichtiger Stakeholder
Damit Eure Sprint Review gut funktioniert und ihren Zweck erfüllt, müssen die wichtigsten Stakeholder an ihr teilnehmen. Ihre Rolle kann nicht durch Dich als Product Owner ersetzt werden. Die Scrum Review ist kein teaminterner Scrum Event, sondern soll sowohl innerhalb Deiner Organisation als auch in Richtung Deiner Kunden und Nutzer Transparenz erzeugen.
Selbstverständlich musst Du nicht zu jeder Sprint Review stets alle Stakeholder einladen. Es reicht vollkommen aus, wenn Du gezielt diejenigen Stakeholder einlädst, die wichtiges Feedback zum aktuellen Stand Deines Produktes geben können und sollen.
Präsentation des Sprint-Ergebnisses
Natürlich ist die Sprint Review auch der Ort, an dem Euer Scrum Team neue Funktionen Eures Produktes präsentiert, um Feedback von den eingeladenen Stakeholdern zu erhalten. Im Normalfall sollte dabei nur das präsentiert werden, was wirklich fertig ist und Eurer Definition of Done entspricht. Unfertige beziehungsweise halbfertige Features erzeugen meist wenig bis gar keine Transparenz, die gutes Feedback ermöglicht.
Die Demonstration neuer Funktionen ist jedoch kein Abnahmeprozess von User Stories durch Dich als Produkt Owner. (Scrum kennt einen solchen Prozess gar nicht.) Dass eine Funktion “richtig” umgesetzt wurde, wird durch die Definition of Done Eures Teams und ein gutes Backlog Refinement gewährleistet. Solltest Du als Product Owner (oder Deine Stakeholder) überrascht sein, was in der Sprint Review gezeigt wird, ist das deshalb ein gutes Zeichen dafür, dass Eure Definition of Done nicht stark genug ist oder die im Refinement festgehaltenen Akzeptanzkriterien nicht klar genug waren.
Fortschritt des Produktes in Hinblick auf das Produktziel
Ein weiterer wichtiger Aspekt jeder guten Sprint Review ist der Fortschritt, den Euer Produkt hinsichtlich des Produktziels gemacht hat. Hierbei geht es also um Fragen wie: Wurde das Sprintziel erreicht? oder Ist das Ergebnis wirklich ein weiterer Schritt in Richtung Produktziel gewesen?
Bestenfalls beinhaltet Euer aktuelles Produktziel konkrete Metriken, an denen der Fortschritt des letzten Sprints klar visualisiert werden kann. (Und an dieser Stelle meine ich jetzt nicht den Umfang an Story Points, den Euer Produkt Backlog beinhaltet, sondern ergebnisorientierte Metriken, wie sie beispielsweise im Evidence-Based Management genutzt werden.)
Ausblick auf Termine und Deadlines
Diese Prognose lässt sich sehr gut mit Hilfe eines Burndown Charts abbilden. Um der verbleibenden Komplexität der Produktentwicklung Rechnung zu tragen, kannst Du als Product Owner auch auf die sogenannte Velocity Range zurückgreifen, weil sie genau diesem Aspekt berücksichtig.
Beispiel für ein Release Burndown Chart mit Velocity Range
Blick auf die aktuelle Marktsituation und andere relevante Entwicklungen
Hier geht es Fragen wie: Welche neuen gesetzlichen Regelungen haben Einfluss auf unser Produkt?, Wo zeichnet sich neues Wachstumspotenzial ab? oder Gibt es Neueinsteiger in unserem Markt und welche Bedeutung haben sie für uns?
Diese Informationen können dabei sowohl durch Dich als Product Owner als auch durch die anwesenden Stakeholder erfolgen.
Anpassung des Produkt Backlogs
Alle bisher genannten Punkte dienen dazu, gemeinsam zu überlegen, welchen Einfluss all das auf Euer Product Backlog hat. (Leider wird dieser Teil der Sprint Review wie erwähnt gerne ausgespart.)
Wenn Ihr also erkennt, dass Ihr zu einem festen Release-Termin nicht alle Funktionen liefern könnt, müsst Ihr gemeinsam überlegen, auf welche Features Ihr vorerst verzichten möchtet. Falls Ihr entdeckt, dass sich Eure Marktsituation durch ein Start-up-Produkt radikal verändert hat, müsst Ihr entscheiden, welche neuen Features ins Product Backlog aufgenommen werden sollten und welche Product Backlog Items keinen Sinn mehr ergeben.
Eure Sprint Review ist nur dann wirklich erfolgreich, wenn Ihr die entstehende Transparenz nutzt, um Anpassungen am Product Backlog vorzunehmen.
Fazit zur Sprint Review
Ich hoffe, ich konnte Dir den Sinn und Zweck der Sprint Review ein wenig näher bringen. Und Dir durch die genannten Punkte dabei helfen, das Element der Anpassung in diesem Scrum Event nicht zu vergessen. Die Sprint Review ist kollaborativer Workshop, den Ihr gemeinsam mit Euren wichtigen Stakeholdern durchführt und kein Präsentationstermin.
Wenn Du noch Fragen zur Sprint Review, Ideen, Feedback oder Kritik zum Artikel hast, freue ich mich wie immer über eine Nachricht unten in den Kommentaren!
