Als agile Organisation versuchen wir uns stetig zu verbessern. Daher halten wir regelmäßig nach unseren Pain-Points Ausschau. Ein solcher Punkt ist für uns die schwankende Qualität unserer Sprint Reviews. In dem Bestreben, unsere Reviews besser zu gestalten, haben wir eine interne Umfrage gestartet und gefragt, welche Eindrücke die Kolleginnen und Kollegen von ihren Reviews haben. Das Feedback von Entwicklerinnen, Scrum Mastern, Product Ownern und Projektleiterinnen haben wir ausgewertet und konnten diese 5 Empfehlungen herausarbeiten, die von den Teams direkt berücksichtigt werden können:

1. Frühzeitige Abnahmen durch den Product Owner

Werden Stories bereits vor dem Review durch den Product Owner abgenommen, wirkt sich dies positiv auf das Meeting aus. So kann bereits eine Präsentation gegenüber den Stakeholdern und Kunden geübt werden und der Product Owner kann einen groben Plan für das Review aufstellen. Mögliche Stolperfallen können frühzeitig erkannt und beseitigt werden. Der Mehraufwand für den Product Owner rechtfertigt sich durch das schnelle Feedback zum Fortschritt.

2. Review vorher dokumentieren

Im Vorfeld des Reviews sollte das Dev-Team eine Dokumentation in einem entsprechenden Tool anlegen (z.B. Confluence). Hierbei können sie sich nochmal Zeit für die Vorstellung der Ergebnisse nehmen. Der Ablauf des Reviews kann ebenfalls nochmal hinterfragt und somit verbessert werden. Ist es möglich, so kann die Dokumentation so gestaltet werden, dass die Ergebnisse schnell abgerufen werden können z.B. mit Hilfe von Verlinkungen. Alle Stakeholder können sich – wenn gewollt – auf das Review vorbereiten und auch im Nachhinein alle Ergebnisse einsehen.

3. Der Product Owner moderiert das Review

Im Review kann das Team die neuen Funktionalitäten den Stakeholdern vorstellen. Eine Moderation durch die/den Product Owner ist jedoch sinnvoll, da dieser einen Gesamtüberblick über die Themen hat. Bei erfahrenen Teams und eingespielten Prozessen, kann hier der Moderationsanteil durchaus reduziert werden.

4. Es wird immer etwas präsentiert

Die Ergebnisse eines Sprints müssen den Stakeholdern präsentiert werden. Bei neuen Features ist das relativ einfach, da die neue Funktionalität an sich gezeigt werden kann, aber bei Bugfixes, Refactorings o.ä. kann dies schwer werden. Hier können jedoch Metriken gezeigt werden, am besten wenn der Zustand vor der Änderung mit dem Aktuellen verglichen wird. Ein Review bei dem nichts gezeigt wird, bleibt hingegen negativ in Erinnerung.

5. Die geplante Zeit wird genutzt

Das Review dient nicht nur dazu Ergebnisse zu präsentieren, sondern auch Erkenntnisse aus diesen zu ziehen. Daher sollte die Zeit auch für einen kleinen Ausblick genutzt werden (“Weil wir XY geschafft haben, können wir jetzt Z machen”). Eine Diskussion mit den anwesenden Stakeholdern kann sich motivierend auf die Zusammenarbeit auswirken. Das Ziel sollte stets sein, mindestens 75% der eingeplanten Zeit zu verwenden. Natürlich ist es auch möglich, den Zeitrahmen des Sprint Reviews jederzeit anzupassen.

Regeln schaffen Sicherheit

Grundsätzlich zielen diese Vorschläge darauf ab, dass ein guter Plan für das Review besteht und sich alle aus dem Team bereits während des Sprints mit dem Review beschäftigen. Zentrale Rolle nimmt hier der Product Owner ein, der Scrum Master kann jedoch unterstützend agieren. Mit Hilfe dieser Liste können wir zumindest einen gewissen Standard für die Reviews herstellen, sodass Schwankungen ins Negative schwächer ausfallen sollten.

Anm.: Der Artikel entstand aus einer Zusammenarbeit zwischen dem Autor Nabil Antar sowie zwei Kollegen Klaas Koester und Mario Meltzow.