Sprint-Review: Zweck, Teilnehmer und Ablauf

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 einer Anpassung des Produkt-Backlogs. 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: Angesichts dessen, was wir gerade entwickelt haben, was sollten wir als Nächstes entwickeln?

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 Dinge, die bei der Planung niemand erwähnt hat. Diese Reaktion ist das Ergebnis des Meetings. Sie fließt direkt in das Produkt-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 die gleiche konkrete Grundlage, auf die sie reagieren können. Wenn jedoch die Demo das Einzige ist, was geschieht (das Team präsentiert, die Stakeholder klatschen, alle gehen), haben Sie eine einseitige Präsentation durchgeführt. Die Review ist der gegenseitige Austausch, 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 agiles 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 bewertet wird.
• Zeigen Sie ein funktionsfähiges Produkt, keine Folien. Demonstrieren Sie das tatsächliche Produkt anhand der Definition von „fertig“. Lassen Sie „fast fertig“ außer Acht. 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 die Sitzung 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 mehr wert 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 hinter verschlossenen Türen reflektiert. 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.

Beides lässt sich nicht gut miteinander vereinbaren. Niemand spricht vor dem Kunden das Thema „Unsere Tests werden überstürzt durchgeführt“ an, sodass eine stillschweigende Zusammenlegung der beiden Veranstaltungen die ehrliche Seite zunichte macht. Den vollständigen Vergleich, einschließlich der Frage, wer an welcher Veranstaltung teilnimmt und warum diese getrennt bleiben sollten, finden Sie unter Sprint-Review vs. Sprint-Retrospektive. Informationen dazu, wo beide im Rahmen der übrigen Meetings angesiedelt sind, finden Sie unter die vier Scrum-Zeremonien und die anderen Zeremonien in diesem Leitfaden.

Häufig gestellte Fragen

Was ist der Zweck einer Sprint-Review?

Um das Produktinkrement gemeinsam mit den Stakeholdern zu begutachten und die nächsten Schritte entsprechend anzupassen. Das Team präsentiert, was es tatsächlich fertiggestellt hat, die Stakeholder reagieren darauf, und diese Reaktion fließt in das Produkt-Backlog ein. Es geht nicht um den Applaus. Es geht um die Kurskorrektur. Eine Besprechung, 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 umsetzenswert ist.

Wie lange sollte eine Sprint-Review dauern?

Legen Sie die Zeitvorgabe 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. Sollte die Zeit überschritten werden, präsentieren Sie wahrscheinlich Folien, anstatt ein funktionierendes Produkt vorzuführen, oder Sie überprüfen Arbeit, die tatsächlich gar nicht erledigt wurde.

Was ist der Unterschied zwischen einer Sprint-Review und einer Demo?

Eine Demo ist eine einzelne Aktivität im Rahmen des Reviews: die Vorführung der funktionierenden Software. Das Sprint-Review ist die umfassendere Diskussion, die durch die Demo in Gang gesetzt wird: Die Beteiligten reagieren, Prioritäten verschieben sich, das Backlog ändert sich. Betrachten Sie das Review lediglich als Demo, und Sie erhalten 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 hinter verschlossenen Türen 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.