Das Review Meeting in SCRUM

Ziele des Review Meetings

Das Review Meeting dient in erster Linie dazu, den Stakeholdern die in dem Sprint umgesetzten und getesteten Features zu präsentieren. Hierbei übernimmt das Team die Vorbereitung und die Durchführung des Meetings. Wichtig ist, dass nur fertige und getestete Features – also den Akzeptanzkriterien der User Story als auch der Definition of Done – vorgestellt werden. Hierbei dürfen aber durchaus inkrementelle Produktteile vorgestellt werden. Diese sind per Definition in sich funktionstüchtig auch wenn der komplette Funktionsumfang noch nicht gegeben ist (bspw. Registrierung funktioniert, automatische Validierung der Eingabefelder erfolgt erst im kommenden Sprint).

Die Stakeholder haben nun die Möglichkeit die Ergebnisse zu betrachten und zu prüfen, ob diese den gestellten Anforderungen entsprechen. Hierbei ist stark darauf zu achten, dass neue Features als solche behandelt werden und durch den Product Owner in das Backlog aufgenommen werden. Lediglich Features die gemäß den Akzeptanzkriterien der User Stories fehlen, müssen je nach Bedarf vor einem Go-Live noch umgesetzt werden (was bei einer guten User Story Beschreibung und einem genauen Testing nicht passieren dürfte – in der Praxis aber immer wieder geschieht).

Beschreibung und Vorgehen

Das Review Meeting findet am Ende eines jeden Sprints statt und wird wie oben erwähnt durch das SCRUM Team durchgeführt. Einleitende Worte durch den Product Owner oder ein Teammitglied über die gesetzten Sprintziele geben einen guten Einstieg in das Meeting.

Die Vorstellung der Ergebnisse des letzten Sprints sollte möglichst nah an dem Livesystem erfolgen (bspw. auf einem Test- oder Stagingsystem). Eingeladen werden alle Stakeholder unter Bekanntgabe einer Agenda ca. 2 Arbeitstage im Vorhinein. So können sie selbst entscheiden, ob eine Teilnahme sinnvoll ist (bspw. wenn kein Feature des Fachbereichs vorhanden ist).

Teilnehmer

  • SCRUM Master
  • Product Owner
  • Team
  • Stakeholder

Input

  • Features des letzten Sprints

Output

  • Ggf. neue Anforderungen/ Featureerweiterungen oder -verbesserungen
  • Kritische Bugs/ Nicht erfüllte User Stories

Frequenz und Dauer

  • Jeweils am Sprintende
  • ca. 1 Stunden

Owner

  • Team

Tipps für ein erfolgreiches Review-Meeting

  • Agenda und Einladung

    • Geben Sie den Stakeholdern 2-3 Arbeitstage vor dem Meeting Zeit sich mit der Agenda auseinanderzusetzen. Ggf. sind die gestellten Anforderungen nicht mehr präsent und müssen zunächst noch einmal erneut in Erinnerung gerufen werden
  • Features/ Bugs

    • Es ist nicht ratsam größere Diskussionen über Bug vs. Feature Diskussionen vor so großer Runde zu führen. Wünsche aufzunehmen und diese über zeitliche Planung im Nachgang mit der entsprechenden Person zu diskutieren ist hierbei ratsam.
  • Vorbereitung

    • Dieses Meeting ist eines der wenigen Meetings, was nicht durch den SCRUM Master oder Product Owner geleitet oder vorbereitet wird. Und dies auf gutem Grund: Das Team hat die Ergebnisse gemeinsam erreicht und kann einerseits auch besser die Umsetzungen erläutern (insbesondere wenn technische Rückfragen bestehen) andererseits soll auch das Team der Lorbeeren bei guter Umsetzung ernten. Das Sprintziel wurde durch das Team definiert und die Übernahme der Verantwortung für die Präsentation der Sprintergebnisse erhöht auch an dieser Stelle das Commitment hierauf.