Als Scrum Master habe ich schon an sehr vielen Sprint Reviews teilgenommen und mir dabei oft die Frage gestellt: „Wie bekomme ich mehr und brauchbareres Feedback im Review?“
In diesem Blogpost möchte ich meine Erfahrung teilen und zeigen, wie nützliches Feedback gefördert werden kann. Außerdem werde ich meine Fehler nennen, die dazu führten, dass kein brauchbares Feedback gegeben wurde.
Der Scrum Guide definiert das Sprint Review als ein informelles Meeting, das die Stakeholder und das Scrum-Team zusammenbringt, um sich mit den Ergebnissen des Sprints zu befassen. Das (Produkt-)Inkrement wird dabei überprüft und das Product Backlog bei Bedarf angepasst. Die Vorführung des Inkrements ist dabei als Anregung für Feedback gedacht.
Das Sprint-Review-Meeting ist kein Statusreport-Meeting, sondern bildet die Grundlage für die gemeinsame Arbeit an möglichen neuen, den Wert des Produkts steigernden User Stories. Dafür ist man auf das Feedback der Stakeholder angewiesen.
Das Sprint Review ist eine Leistungsnachweis-Show
Ich habe leider allzu oft erlebt, dass ein Sprint Review missbraucht wird, um die Leistung des Teams zu präsentieren. In eine Leistungsnachweis-Show verwandelt sich das Meeting ganz schnell, wenn neben den Sprint-Ergebnissen auch noch Zahlen zu den vergangenen Wochen gezeigt werden:
- Welche Velocity hatte das Team?
- Wie viele Spikes wurden gemacht?
- Welche Kapazität an Teammitgliedern hatte man zu Sprintbeginn, welche am Sprintende?
- Wie gut war das Team im Schätzen?
All diese Zahlen lenkten vom eigentlichen Grund des Meetings ab: Zusammen mit den Stakeholdern soll über das Sprint-Inkrement sowie zukünftige Storys gesprochen werden und nicht darüber, dass die Velocity erhöht wurde.
Ich habe gelernt, dass hier Erwartungsmanagement betrieben werden sollte. Eine kurze Einleitung zu Beginn des Meetings kann allen Teilnehmer helfen zu verstehen, was gezeigt wird und wie man Feedback zum Sprint-Ergebnis gibt. Wir haben sogar einmal ein „How to Review Meeting“ zusammengeschrieben – darin steht beispielsweise, das „Outcome statt Output“ zu betrachten sei und eine kurze Anleitung, wie wertbringendes Feedback gegeben werden kann.
Die falsche Zielgruppe kommt zum Review
Bei einem großen Projekt sind in der Regel mehrere Stakeholder beteiligt, die auch ein Interesse am Sprint Review haben. Bedingt durch die verschiedenen User Stories, die man in einem Sprint abarbeitet, kann es vorkommen, dass in einem Review für einen Stakeholder weniger interessante Ergebnisse gezeigt werden. Das führt dazu, dass das Feedback des Stakeholders weniger zur Weiterentwicklung des Produkts beiträgt.
Abhilfe kannst du schaffen, indem du Teilnehmer gezielt einlädst bzw. Erwartungsmanagement betreibst und ankündigst, was gezeigt werden wird. Zusätzlich möglich ist ein Sprint Review mit Motto oder nur zu bestimmten Themen. Probiert es doch einmal aus, ihr werdet sehen, das Feedback wird ein ganz anderes sein.
Nur technische Stories oder wenig Testbares im Review
Für Teilnehmer am Review kann es sehr langweilig und unattraktiv sein, wenn nur sehr technische Storys im Sprint waren und die Ergebnisse dazu am Ende im Review gezeigt werden. Über die Jahre habe ich gelernt „Gibt es wenig zu sehen und auszuprobieren, kommen Gespräche und Diskussionen nur schwer in Gang!“.
Natürlich sollen User Stories immer vertikal geschnitten sein, das bedeutet, dass alle Layer von der Datenbank bis zum Frontend involviert sein sollten. Es gibt in der Praxis sicher Gründe, warum das nicht möglich sein kann. In diesem Fall sollte sich das Team bereits im Planning Gedanken machen, was im Review gezeigt werden kann. Mit diesem Wissen kann auch wieder Erwartungsmanagement betrieben und die Stakeholder informiert werden. Das Sprint-Ziel sollte so gewählt werden, dass es zeigbar ist.
Einmal Zurücklehnen bitte, wir laden ein zum PowerPoint-Kino
Ich kann gar nicht zählen, wie oft ich einen Product Owner beim Erstellen einer PowerPoint-Präsentation für das Sprint Review unterstützt habe. Leider viel zu oft!
Natürlich ist das eine einfache und zeitsparende Art, das Ergebnis des vergangenen Sprints zu zeigen, jedoch sollte für das Team kein extra Aufwand für das Review geleistet werden. Zusätzlich wird man nur Feedback zu dem bekommen, was gezeigt wird. Viel besseres und auch wesentlich mehr Feedback bekommt das Team, wenn das Sprint-Inkrement selbst ausprobiert werden kann. Ich weiß, das bietet sich nicht immer an, jedoch reicht oft schon ein einfacher Click Dummy einer frühen Version, um Diskussionen entlang des Produkts (und dessen Verbesserung) zu starten.
Es gibt dafür viele Formate. Wir haben gute Erfahrungen mit dem Review-Marktplatz gemacht, ähnlich wie es im agilen Skalierungsframework LeSS empfohlen wird. Dazu können Stakeholder und andere Interessierte den ganzen Tag zu uns in den Teamraum kommen und auf drei vorbereiteten (unterschiedlichen) Geräten das Resultat des letzten Sprints live testen. Neben den Geräten stehen Stifte und Papier zur Verfügung, um Feedback zu geben; ein persönliches Gespräch ist natürlich auch möglich, es sind immer Teammitglieder am „Teststand“. Aus diesem Format haben wir bereits viele neue User Stories generieren können.
Feedback erwünscht!
Was sind Eure Tipps, um mehr Feedback im Review Meeting zu fördern? Nutzt Ihr auch manchmal ein anderes Format? Falls ja, bin ich ganz gespannt und würde mich über Eure Erfahrungen und Tipps als Kommentar sehr freuen :-)
Schreibe einen Kommentar