dot.tipp - Wie man den perfekten Scrum Sprint Review durchführt?

2 Minuten Lesezeit
21. Mai 2019
dot.tipp - Wie man den perfekten Scrum Sprint Review durchführt?
3:35

Der Sprint Review ist eine unterschätzte Zeremonie. Gewöhnliche Sprint Reviews enden in einseitigen Demonstrationen erledigter Funktionen, derweil die Stakeholder sich langweilen. In diesem Beitrag möchten wir Ansätze skizzieren, wie man einen Sprint Review im Sinne der Erfinder (Scrum Guide!) gestalten könnte.

Der Sinn und Zweck des Sprint Review

Der Scrum Guide klärt unmissverständlich, was ein Sprint Review ist:

Beim Sprint Review handelt es sich um ein informelles Meeting, keinen Statusreport. Die Vorführung des Inkrements ist als Anregung für Feedback und die Basis für die Zusammenarbeit gedacht.

Der Sprint Review ist folglich keine perfekt orchestrierte Marketing-Veranstaltung zugunsten des Scrum Teams, sondern eine Art Werkstatt, Open Space für Ideen, Innovationen und vor allem fürs gemeinsame Lernen und gegenseitige Verständnis.

Ich habe in Vergangenheit zu viele monotone und einseitige Sprint Reviews erduldet, wo das offensichtlich extrovertierteste Mitglied des Scrum Teams - oder schlimmer noch, der Product Owner selbst - stundenlang über unbedeutende Funktionen elaborierte. Das habe ich geändert. Seitdem praktiziere ich den Sprint Review offener.

Die ultimative Agenda für den Sprint Review

Für den Sprint Review empfehle ich eine minimale, aber strenge Agenda:

1) Einleitung

Hier sollen nochmals der Sinn und Zweck des Sprint Reviews verdeutlicht werden. Der Sprint Review ist eine Veranstaltung, um gemeinsam zu lernen, Erfahrungen zu teilen, den Product Backlog zu aktualisieren, Feedback-Zyklen zu verkürzen. Und so weiter. Aber keine Präsentation Potemkinscher Dörfer.

2) Ein Höhepunkt des Sprints

Hier kann das Scrum Team einen Aspekt des Produkts und/oder des Sprints der Allgemeinheit frontal vorstellen. Dieser Abschnitt soll auf zwanzig Minuten begrenzt werden.

3) Basar und/oder Open Space

Das ist der Kern des Sprint Reviews. Je nach Grösse/Skalierung der Scrum Organisation ist hier ein Open Space oder Basar Format oder eine Kombination derselben anzuwenden.

Basar Format

Der Basar eignet sich für eine skalierte Umgebung. Den Basar kann man nach Teams schneiden, sofern die Teams autonom und unabhängig voneinander sind. Falls mehrere Teams notwendig sind, um ein einzelnes Epic zu implementieren, kann der Basar auch nach Epics gruppiert werden. An den Ständen beantwortet das Entwicklungsteam Fragen der Stakeholder, demonstriert Funktionen oder aktualisiert gemeinsam den Produkt Backlog.

Open Space Format

Der Open Space ist für kleinere wie grössere Scrum Organisationen prädestiniert. Die Stakeholder und die Scrum-Organisation sammeln die gewünschten Themen, priorisieren gemeinsam und erarbeiten in spontanen Kleingruppen Ergebnisse, die sie dann anschliessend dem Plenum wieder zurückspiegeln. Die Themen müssen sich aufs Produkt beziehen. Methodische Themen dürfen zwar angesprochen werden, diese sind aber in einer Retrospektive bekanntlich besser aufgehoben.

4) Sprintabschluss

Nun kann der Sprint offiziell geschlossen werden. Kennzahlen dürfen konsultiert werden, falls gewünscht. Das Burndown-Chart, obwohl seit 2011 nicht mehr vom Scrum Guide eingefordert, oder das Velocity-Chart veredeln den Sprintabschluss.

Und dein Sprint Review?

Ein professioneller Scrum Master kann einen Sprint Review ganz im Sinne des gemeinsamen Lernens vorbereiten und durchführen. Wir unterstützen dich gerne. Alternativ lass dich zum Professional Scrum Master ausbilden.

Keine Kommentare

Teile deine Meinung

Werde per Email über neue Blogs informiert