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 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 die Demo auslöst.

Wozu dient die Sprint-Review?

Der Rückblick dient dazu, gemeinsam mit denjenigen, denen das Ergebnis am Herzen liegt, eine Frage zu beantworten: Angesichts dessen, was wir gerade umgesetzt haben, was sollten wir als Nächstes umsetzen?

Das Team präsentiert das Inkrement – also die Arbeit, die gemäß der Definition von „fertig“ tatsächlich erledigt wurde, nicht die Arbeit, die fast fertig ist – und die im Raum anwesenden Stakeholder reagieren darauf. Sie stellen Fragen, sie bringen Einwände vor, sie bemerken Dinge, an die bei der Planung niemand gedacht 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, die funktionierende Software zu zeigen: Das zwingt zur Ehrlichkeit (man kann keine fast fertige Funktion vorführen) und gibt allen die gleiche konkrete Grundlage, auf die sie reagieren können. Wenn jedoch die Vorführung das Einzige ist, was geschieht – das Team präsentiert, die Stakeholder klatschen, alle gehen –, dann haben Sie eine einseitige Präsentation durchgeführt. Die Besprechung ist der wechselseitige Dialog, den die Demo eigentlich in Gang setzen soll. Die Demo ist die Vorbereitung; das Feedback und die Neugewichtung der Prioritäten sind der eigentliche Sinn.

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, Supportmitarbeiter und alle, deren Reaktion Einfluss auf das Produkt haben sollte.

Diese Gästeliste ist eine Entscheidung, keine Formalität. Laden Sie Personen ein, die Feedback geben können, das es wert ist, umgesetzt zu werden, 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 Überprüfung 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 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.

Sie lassen sich nicht gut miteinander vereinbaren – niemand spricht vor dem Kunden das Thema „Unsere Tests werden überstürzt durchgeführt“ an, sodass eine stillschweigende Zusammenlegung die ehrliche Hälfte zunichte macht. Den vollständigen Vergleich, einschließlich der Frage, wer an welcher Veranstaltung teilnimmt und warum diese getrennt gehalten werden, 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 weiteren Schritte entsprechend anzupassen. Das Team präsentiert, was es tatsächlich fertiggestellt hat, die Stakeholder reagieren darauf, und diese Reaktion fließt zurück in das Produkt-Backlog. Es geht nicht um den Applaus – es geht um die Kurskorrektur. Eine Besprechung, die nichts am Plan ändert, war nichts anderes als ein getarntes Statusmeeting.

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 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 Sprint. Sollte die Zeit überschritten werden, präsentieren Sie wahrscheinlich Folien, anstatt ein funktionierendes Produkt vorzuführen, 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 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. Wenn Sie das Review 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 intern begutachtet – um zu erörtern, wie im nächsten Sprint besser gearbeitet werden kann. 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.