Scrum#3 - Review Meeting erfolgreich gestalten

Nach jedem Sprint müssen die implementierten Features dem Product Owner und den interessierten Stakeholdern durch das Entwicklerteam im Rahmen eines sogenannten Review-Meetings präsentiert werden.

Dabei werden alle neue Funktionalitäten gemäss den "commited" Userstories aus dem Sprint-Backlog an einem Live-System vorgestellt, um den Auftraggebern das Resultat aus dem vergangenen Sprint zeigen zu können.

Ein essentieller Punkt dabei ist, dass dadurch sofort Feedback eingeholt werden kann. Die Auftraggeber bewerten das Gezeigte und geben einerseits Feedback (Verbesserungsvorschläge, Kritik aber auch Lob) zu den Implementierungen und andererseits, ob der Sprint als Ganzes erfüllt wurde. Dadurch wird nach jedem Sprint implizit der Fortschritt für das zu realisierende Gesamtprodukt geprüft. Falsche, unvollständige Ergebnisse werden dadurch spätestens nach jedem Sprintabschluss transparent gemacht und es können umgehend Massnahmen durch den Product Owner und das Entwicklerteam eingeleitet werden; dies können beispielsweise Umpriorisierungen der Userstories im Product Backlog sein.

Quelle: seattlescrum.com

Ziele des Meetings sind:

• Feedback des Product Owners und den Stakeholder sammeln (Kritik, Verbesserungsvorschläge und Lob)
• die neuen Features werden auf einem lauffähigen System "live" präsentiert (es wird sozusagen bewiesen, dass die neuen Implementierungen auch funktionieren)
• Probleme und Fortschritte werden transparent
• der Product Owner kann den Fortschritt messen und allfällige Massnahmen einleiten (Anpassung des Product Backlogs)
• formeller Abschluss für den vergangenen Sprint

Best Practices:

• Es bewährt sich, wenn sich das Entwicklerteam die erforderliche Zeit nimmt und das Review-Meeting im Voraus gut vorbereitet. Dabei ist nicht der Scrum Master federführend, sondern das Entwicklerteam. Es entscheidet, was gezeigt wird und welche Entwickler die neuen Features präsentieren.
• Das Review Meeting ist "timeboxed" - zum Beispiel max. 1 Stunde bei einem 2-Wochen Sprint
• Die Teilnahme von Stakeholder bewährt sich. Die Stakeholder erhalten die Möglichkeit das neue Produkt fortlaufend zu begutachten und Ihre Einschätzungen zeitnah platzieren zu können.
• Der grobe Ablauf des Review Meetings wird durch den Scrum Master moderiert. Dazu gehören Begrüssung, Agenda Einholung des Sprint-Status und der Ausblick auf den nächsten Sprint. Zudem stellt der Scrum Master sicher, dass Diskussionen nicht abschweifen und die Timebox eingehalten wird.
• der Scrum Master holt proaktiv das Feedback vom Product Owner und allenfalls der Stakeholder ein un notiert sich alle relevanten Informationen aus den Gesprächen (Feedback, Rückfragen, Vorschläge, aber auch Lob der Stakeholder und Product Owner) und verfasst nach dem Meeting ein kurzes Protokoll. Dadurch erhält das Meeting auch einen formellen Charakter und es ist vermerkt, ob der Sprint aus Sicht des Product Owners erfüllt ist. Wichtig: das Protokoll soll schlank bleiben!
• Die eigentlichen Präsentation müssen durch die Entwickler an einem laufenden System erfolgen. Dabei stellen die Entwickler ihre im Sprint selber implementierten neuen Features vor.
• Wenn möglich sollten die Entwickler die neuen Features nicht auf Ihren Entwicklergeräten (bspw: http://localhost) präsentieren, denn dies erweckt den Eindruck, dass das versprochene Feature doch noch nicht ganz fertig ist. Daher sollten die fertigen Features über den ordentlichen Deploymentprozess vorgängig auf eine Testumgebung oder sogar produktiv eingespielt und dort präsentiert werden. So haben Product Owner und Stakeholder nach dem Review Meeting ebenfalls die Möglichkeit, die neuen Features gleich selber auszuprobieren

Anwendung:

• Die Teilnahme des Entwicklerteams, des Product Owners und des Scrum Masters ist Voraussetzung. Stakeholder, User oder Testmanager können optional eingeladen werden.
• Eine gleichbleibende Agenda und Timebox des Review-Meetings ist hilfreich. Nach einigen Sprints kennen dadurch alle Teilnehmer den Ablauf und halten sich an die vorgegebene Zeit.
• Das Meeting sollte an einem Ort stattfinden, wo ungestört präsentiert und diskutiert werden kann. Zudem müssen die technischen Hilfsmittel vorgängig in Betrieb genommen und geprüft werden. Wenn sich der Scrum Master dafür Zeit nimmt, kann das Meeting pünktlich und ohne unvorhergesehenen Probleme gestartet werden.