Sprint-Review: Zweck, Teilnehmer und Durchführung
Die Sprint-Review ist die Veranstaltung, bei der das Team den Stakeholdern ein funktionsfähiges Produkt vorstellt und Feedback einholt, das in die Neugestaltung des Backlogs einfließt. Es handelt sich um eine Arbeitssitzung, nicht um eine Demo.
Die Sprint-Review ist die Zeremonie, bei der das Team den Stakeholdern ein funktionsfähiges Produkt vorstellt und Feedback einholt, das die Gestaltung der nächsten Entwicklungsschritte beeinflusst. Sie findet am Ende des Sprints statt, ist bei einem zweiwöchigen Sprint auf etwa zwei Stunden begrenzt und führt zu einem angepassten Product Backlog. Das Wichtigste dabei: Es handelt sich um eine Arbeitssitzung, nicht um eine Vorführung. Der Wert liegt nicht in der Demo selbst, sondern in den Entscheidungen, die durch die Demo ausgelöst werden.
Wozu dient die Sprint-Review?
Der Rückblick dient dazu, denjenigen, denen das Ergebnis am Herzen liegt, eine Frage zu beantworten: Was sollten wir als Nächstes entwickeln, ausgehend von dem, was wir gerade geschaffen haben?
Das Team präsentiert das Inkrement (die tatsächlich erledigte Arbeit gemäß der Definition von „fertig“, nicht die Arbeit, die fast fertig ist), und die im Raum anwesenden Stakeholder reagieren darauf. Sie stellen Fragen, sie hinterfragen, sie bemerken das, was bei der Planung niemand erwähnt hat. Diese Reaktion ist das Ergebnis des Meetings. Sie fließt direkt in das Product Backlog ein, das der Product Owner sofort oder kurz danach anpasst.
Sprint-Review vs. Demo
Die Leute verwenden die Begriffe „Sprint-Review“ und „die Demo“, als handele es sich um ein und dieselbe Besprechung. Das ist jedoch nicht der Fall: Die Demo ist nur ein Teil des Reviews.
Es ist wichtig, funktionierende Software zu präsentieren: Dies fördert Ehrlichkeit (Sie können keine fast fertige Funktion vorführen) und gibt allen Beteiligten denselben konkreten Anhaltspunkt, auf den sie reagieren können. Wenn jedoch die Demo das Einzige ist, was geschieht (das Team präsentiert, die Stakeholder klatschen, alle gehen), haben Sie lediglich eine einseitige Präsentation durchgeführt. Die Review ist der wechselseitige Dialog, den die Demo eigentlich anstoßen soll. Die Demo ist die Vorbereitung; das Feedback und die Neugewichtung der Prioritäten sind der eigentliche Sinn. Eine Demo, die nur um des Beifalls willen durchgeführt wird, ohne dass Entscheidungen daraus folgen, ist agile Theater: eine Zeremonie, die für das Publikum statt für das Ergebnis inszeniert wird.
Wer nimmt daran teil, und warum ist die Veranstaltung öffentlich?
Die Sprint-Review ist die einzige Zeremonie, die nach außen gerichtet ist. Zu den Teilnehmern gehören das gesamte Scrum-Team sowie die vom Product Owner eingeladenen Stakeholder: Kunden, Nutzer, Sponsoren, Support-Mitarbeiter und alle, deren Feedback Einfluss auf das Produkt haben sollte.
Diese Gästeliste ist eine Entscheidung, keine Formalität. Laden Sie Personen ein, die umsetzbares Feedback geben können, und gehen Sie bei der Auswahl gnadenlos vor: Ein Raum voller Zuschauer erzeugt höfliches Geschwätz; ein Raum mit den richtigen drei Kunden führt zu einem neu geordneten Backlog. Genau diese nach außen gerichtete Haltung unterscheidet die Review von der Sprint-Retrospektive, die aus gutem Grund nur dem Team vorbehalten und privat ist.
Wie man eine Veranstaltung durchführt, die diese Stunde wert ist
Das Format ist bewusst locker gehalten. Bitte gestalten Sie die Veranstaltung als Arbeitssitzung und nicht als Bühnenshow.
- Beginnen Sie mit dem Ziel des Sprints. Erinnern Sie die Anwesenden daran, was mit diesem Sprint erreicht werden sollte, damit das Ergebnis anhand der ursprünglichen Absicht und nicht anhand der allgemeinen Stimmung beurteilt wird.
- Zeigen Sie ein funktionsfähiges Produkt, keine Folien. Demonstrieren Sie das tatsächliche Produkt anhand der Definition von „fertig“. Lassen Sie „fast fertig“ weg. Dies führt zu Diskussionen über Arbeit, die noch nicht abgeschlossen ist.
- Schaffen Sie Raum für Reaktionen. Das Team sollte mehr zuhören als präsentieren. Fragen, Einwände und „Könnte man auch …“ sind genau das, wofür Sie gekommen sind.
- Schließen Sie das Thema ab, indem Sie den Backlog aktualisieren. Beziehen Sie das Feedback in die Prioritäten ein, solange es noch frisch ist. Das ist das Ergebnis der Besprechung.
Bei der Vorbereitung geht es vor allem um Zurückhaltung: Wählen Sie aus, was Sie zeigen möchten, stellen Sie sicher, dass es tatsächlich funktioniert, und widerstehen Sie dem Drang, ein Deck zusammenzustellen. Zehn Minuten, in denen eine Funktion funktioniert, sind besser als vierzig Minuten mit Screenshots davon.
Sprint-Review vs. Sprint-Retrospektive
Die beiden Abschlussveranstaltungen werden häufig verwechselt, daher bitte beachten Sie Folgendes: Bei der Review wird das Produkt gemeinsam mit den Beteiligten begutachtet; bei der Retrospektive wird der Prozess des Teams unter vier Augen begutachtet. Die Review ist nach außen gerichtet und findet zuerst statt; die Retrospektive ist nach innen gerichtet und findet als Zweites statt, damit das Team frisches Produkt-Feedback in seine eigene Reflexion einfließen lassen kann.
Sie lassen sich nicht gut miteinander vereinbaren. Niemand spricht vor dem Kunden das Thema „Unsere Tests werden überstürzt durchgeführt“ an; eine stillschweigende Zusammenlegung würde daher die ehrliche Seite zunichte machen. Wir behalten den vollständigen Vergleich bei – einschließlich der Frage, wer an welcher Veranstaltung teilnimmt und warum diese getrennt bleiben – und unterscheiden zwischen Sprint-Review und Sprint-Retrospektive. Informationen dazu, wo beide im Rahmen der übrigen Besprechungen angesiedelt sind, finden Sie unter den vier Scrum-Zeremonien und den weiteren Zeremonien in diesem Leitfaden.
Häufig gestellte Fragen
Was ist der Zweck einer Sprint-Review?
Um das Produktinkrement gemeinsam mit den Beteiligten zu begutachten und die nächsten Schritte entsprechend anzupassen. Das Team präsentiert, was es tatsächlich fertiggestellt hat, die Beteiligten reagieren darauf, und diese Reaktion fließt in das Produkt-Backlog ein. Es geht nicht um den Applaus. Es geht um die Kurskorrektur. Eine Überprüfung, die nichts am Plan ändert, war nichts anderes als ein Statusmeeting in Verkleidung.
Wer nimmt an einer Sprint-Review teil?
Das gesamte Scrum-Team sowie die vom Product Owner eingeladenen Stakeholder: Kunden, Nutzer, Sponsoren und alle, deren Feedback das Produkt mitgestalten soll. Es ist die einzige Zeremonie, die bewusst nach außen gerichtet ist. Der Product Owner stellt die Gästeliste sorgfältig zusammen, damit das im Raum geäußerte Feedback auch wirklich umsetzenswert ist.
Wie lange sollte eine Sprint-Review dauern?
Legen Sie die Zeitbegrenzung auf etwa zwei Stunden pro Sprintwoche fest: bis zu zwei Stunden für einen zweiwöchigen Sprint, bis zu vier Stunden für einen einmonatigen Sprint. Wenn die Zeit überschritten wird, präsentieren Sie wahrscheinlich Folien, anstatt ein funktionierendes Produkt zu zeigen, oder Sie überprüfen Arbeit, die tatsächlich nicht erledigt wurde.
Was ist der Unterschied zwischen einer Sprint-Review und einer Demo?
Eine Demo ist eine einzelne Aktivität im Rahmen der Review-Sitzung: die Vorführung der funktionsfähigen Software. Die Sprint-Review ist der umfassendere Austausch, den die Demo in Gang setzt: Die Beteiligten reagieren darauf, Prioritäten verschieben sich, das Backlog ändert sich. Wenn Sie die Review-Sitzung lediglich als Demo betrachten, erhalten Sie eine einseitige Präsentation, die zwar zustimmendes Nicken hervorruft, aber keine Entscheidungen hervorbringt.
Was ist der Unterschied zwischen einer Sprint-Review und einer Retrospektive?
Bei der Sprint-Review wird das Produkt gemeinsam mit den Beteiligten begutachtet, um zu entscheiden, was als Nächstes entwickelt werden soll. Bei der Retrospektive wird der eigene Prozess des Teams unter Ausschluss der Öffentlichkeit analysiert, um im nächsten Sprint besser zu arbeiten. Die Review ist nach außen gerichtet und findet zuerst statt; die Retrospektive ist nach innen gerichtet und findet als Zweites statt. Sie benötigen beides, und die beiden lassen sich nicht gut miteinander kombinieren.