Eines der im Scrum Guide beschriebenen Events ist das Sprint Review. Warum gibt es das und was sind die Vorteile?
Vorteile für Product Owner
- Ziel-Erreichung
Klarheit, ob das Sprint-Ziel erreicht wurde oder was zur Ziel-Erreichung fehlte. War das Ziel hinreichend klar und motivierend? In jedem Fall ein mögliches Retro-Thema. - Feedback: Aufgaben-Erklärung
Spätestens im Review erkennen Product Owner und Stakeholder, ob die Entwickler eine hinreichend ähnliche Vorstellung vom geplanten Ergebnis hatten. Abweichungen können zu Nachbesserungsbedarfen führen, die künftig im Vorfeld, bspw. durch häufigere Abstimmungen im Sprint, vermieden werden sollten. - Verbesserung der Team-Kommunikation
Fehlen regelmäßig Dinge, die der Product Owner für selbstverständlich hielt (bspw. Dokumentation), kann er diese Dinge künftig im Planning explizit als erwartete Ergebnisse erwähnen. - Product-Backlog-Ergänzungen
Durch Nachbesserungsbedarfe oder neue Ideen können neue Stories entstehen oder auffallen: Diese müssen im Backlog passend einsortiert werden. - Product-Backlog-Umpriorisierungen
Beim Blick auf das neu Entstandene erkennen Product Owner oder Stakeholder gelegentlich, dass ein im Backlog hoch priorisiertes Thema nun weniger wichtig ist, da das Entstandene dem Ziel des zuvor hoch priorisierten Themas schon nahe kommt. Manchmal fallen Backlog-Items sogar ganz oder teilweise weg.
Vorteile für Entwickler
- Ziel-Erreichung
Klarheit, ob das Sprint-Ziel erreicht wurde oder was zur Ziel-Erreichung fehlte. Wurde das Ziel verfehlt kann dies ein wichtiges Thema der Retrospektive sein. War das Ziel bspw. ausreichend präsent während des Sprints? - Lob
Das Review bietet einen Raum, um gemeinsam stolz auf das Erreichte zu sein (“Werkstolz”). Es kommt auch nicht selten vor, dass zusätzlich zum Lob für die hervorragende Arbeit des Teams besonders kreative Lösungen oder gute Entscheidungen hervorgehoben werden. - Feedback: Aufgaben-Verständnis
Entspricht eine Umsetzung nicht der Vorstellung des Product Owners oder der Stakeholder kann ich als Entwickler überlegen den Product Owner künftig früher zu fragen oder um ausführlichere Erklärungen bitten. - Feedback: Qualität
Fallen im Review Fehler auf kann ich intensiver testen oder zusätzliche Prinzipien (Clean Code: KISS, …) und Methoden (bspw. Pair Programming) nutzen, um Fehler im Vorfeld zu vermeiden und den Aufwand zur Umsetzung dieser Aktionen im nächsten Planning berücksichtigen. - Zuverlässigere Planung
Am Ende des Reviews ist klar, was wirklich fertig geworden ist und wo Nachbesserungen nötig sind. Nur basierend auf dem Umfang dessen, was wirklich fertig ist, sollte das Team die Inhalte seines nächsten Sprints ziehen (vorbehaltlich planbarer Sonder-Effekten wie Urlauben etc.).
Vorteile für Scrum Master
- Ziel-Erreichung
Klarheit, ob das Sprint-Ziel erreicht wurde oder was zur Ziel-Erreichung fehlte. Gab es Hindernisse, die schneller hätten beseitigt werden können? In jedem Fall ein mögliches Retro-Thema. - Vermeidung von Störungen
Das Review fokussiert das Feedback auf ein einzelnes Event. Gäbe es dies nicht würde das Feedback ungeplant immer mal wieder von der Seite hereinplätschern. - Scrum
Last but not least: Ohne Review kein Scrum. Kurz und knapp.
Feedback
Wenn ihr Anmerkungen, Ideen, Vorschläge oder anderes Feedback zu diesem Artikel habt schreibt mir gern eine Mail an Feedback[at]scrummastersmind.com