Was würdet Ihr als das wichtigste Event ansehen? Die meisten plädieren hier für die Retrospektive. Oder das Daily Scrum. Klar, in der Retrospektive geht es um Verbesserung, im Daily Scrum um Selbstorganisation. Alles wichtig, gerade aus Sicht der Scrum Master:in. Bei diesen Events dreht es sich hauptsächlich um die Innensicht des Teams. Ein Scrum Team ist jedoch kein Selbstzweck, sondern seine Daseinsberechtigung ist es, ein Ergebnis zu liefern und Wert für Stakeholder erzeugen. Wie gut gelingt ihm das? Um diese Außensicht geht es im Sprint Review.

Im Sprint Review diskutieren das Scrum Team und die Stakeholder über das Produkt. Diese Stakeholder gehören nicht zu den im Scrum Guide beschriebenen Rollen bzw. Verantwortlichkeiten, und vielleicht wird ihre Bedeutung daher unterschätzt. Scrum macht (im Gegensatz zum „klassischen“ Projektmanagement) keine expliziten Vorgaben zum Stakeholdermanagement.  Es ist eine wichtige Verantwortung der Product Owner:in, die Stakeholder einzubeziehen. Wohl der, die (in einem früheren Leben als Projektleiterin, oder in einem Advanced Certified Scrum Product Owner Kurs) mal gelernt hat, wie das geht. Oder eine Scrum Master:in an ihrer Seite hat, die sich der Bedeutung bewusst ist. Denn ohne die Unterstützung der Stakeholder kann die Product Owner:in nicht wirksam werden. Zu den Stakeholdern gehören neben den Nutzern auch diejenigen, die den Geldhahn für das Produkt öffnen oder schließen.

Unzureichende Einbeziehung von Stakeholdern kann sich im Review unterschiedlich auswirken:

• das Review findet ohne Stakeholder statt. Die Developper:innen stellen sich die Ergebnisse gegenseitig vor, oder der Product Owner:in. Das sollten sie während des Sprints machen. Wozu sind sie denn sonst ständig zusammen?

• das Review findet mit Stakeholdern statt, aber die sagen nichts. Haben sie das Gefühl, dass ihre Meinung wirklich interessiert und eine Wirkung hat? Hat die Scrum Master:in mit geeigneten Facilitation-Methoden dafür gesorgt, dass ein sicherer Raum für Meinungsäußerung entsteht? Ist einfach die Zeit zu knapp?

• das Review fand früher mal mit Stakeholdern statt, aber jetzt kommen sie nicht mehr. Vielleicht liegt das an der Sprache des Teams: zu technisch, nicht die richtige „Flughöhe“ für Stakeholder? Stakeholder nicht „abgeholt“? Im Gegensatz zu dem Scrum Team ist es nicht ihre alleinige Aufgabe, sich um dieses Produkt zu kümmern, sondern sie haben in der Regel eine Fülle von anderen Aufgaben. Oder gibt es neben dem Sprint Review andere Meetings, Steering Board Committees zum Beispiel, in denen die Stakeholder besser Einfluss nehmen können?

Das Sprint Review ist das Event zum Stakeholder Management in Scrum. Es sollte die Grundlage für Stakeholder sein zu entscheiden, ob sie das Produkt unterstützen und es ggf. weiter finanzieren. Kommunikation mit Stakeholdern sollte auch außerhalb dieses Meetings stattfinden, aber die Zusammenarbeit im Review legt eine wichtige Grundlage dazu. Es entstehen persönliche Beziehungen: Stakeholder tauschen sich mit Scrum-Team-Mitgliedern und untereinander aus. Man lernt die Sprache „der anderen“ zu verstehen: Stakeholder lernen „Tech-Sprech“ und Developer:innen „Business-Sprech“. Man erfährt die Perspektiven der anderen aus erster Hand und entwickelt Verständnis füreinander. So kann die Product Owner:in darauf einwirken, dass Stakeholder nicht gegeneinander arbeiten, um ihre eigenen Interessen durchzusetzen, sondern miteinander an einem gemeinsamen Ziel, das auch mal Kompromisse erfordert.

In einem guten Sprint Review wird nicht nur das Increment des letzten Sprints vorgestellt, sondern über die weitere Richtung der Produktentwicklung diskutiert. Hier ein paar Tipps, wie das gelingen kann:

• Das Scrum Team sollte im Sprint Review keine Überraschungen erleben, die durch bessere interne Kommunikation hätten vermieden werden können. Es kann unangenehm sein, wenn die Product Owner:in erst im Review erfährt, dass eingeplante Product Backlog Items nicht fertig geworden sind. Oder wenn die Product Owner:in den Developper:innen ein negatives Feedback zum Nutzen des Increments gibt. Solche Dinge besser bereits im Sprint klären, damit sie so schnell wie möglich behoben werden.

• Die Scrum Master:in sollte die Moderation des Meetings genauso gut vorbereiten wie die Retrospektive. Gerne mit ein paar ungewöhnlichen Methoden spielen: Ein Sprint Review darf Spaß machen! Aber dabei die Zielgruppe im Auge behalten, die wir nicht vergraulen wollen. Die fünf Schritte zum Ablauf einer Retro sind auch für ein Review sinnvoll:

• Set the stage: Richtig zu starten ist für ein Review noch entscheidender als für die Retro! Da sich die Teilnehmenden seltener sehen und wahrscheinlich mehr Berührungsängste haben, ist es noch wichtiger, für eine offene und vertrauensvolle Atmosphäre zu sorgen. Umgang mit negativem Feedback fällt leichter, wenn auch im Review alle der Prime Directive für Retrospektiven folgen: „Unabhängig davon was wir entdecken werden, verstehen und glauben wir aufrichtig, dass in der gegebenen Situation, mit dem verfügbaren Wissen und Ressourcen und unseren individuellen Fähigkeiten, jeder sein bestes getan hat.“

• Gather Data: Das ist in erster Linie das Increment. Aber auch andere Daten sind relevant, zum Beispiel zur Qualität des Produktes, zum aktuellen Release-Plan oder zur Markt- und Mitbewerbersituation. Sowohl das Scrum Team als auch die Stakeholder können dazu beitragen, dass ein möglichst umfassendes Bild des Produktes entsteht.

• Generate Insight: Das ist der oft vernachlässigte Kern des Reviews. Die Scrum Master:in kann die Diskussion durch spezifische Fragen befeuern. Zum Beispiel: „Auf einer Skala von 1-10, wie beurteilt ihr den Nutzen des Increment? Was wäre notwendig, damit ihr einen weiteren Punkt auf der Skala vergeben würdet?“ Je nach Anzahl der Teilnehmenden kann es sehr sinnvoll sein, Kleingruppen für diesen Austausch zu bilden.

• Decide what to do: Für das Produkt-Ziel und das Product Backlog Management ist die Product Owner:in verantwortlich. Je mehr sie Stakeholder und Developer:innen in diese Entscheidungen einbezieht, desto mehr werden sie von allen gemeinsam getragen werden. Vielleicht kann das Scrum Team bereits im Review entscheiden, dass eine neue Idee in den nächsten Sprint aufgenommen wird. Vielleicht ist es notwendig, zuvor noch ein Refinement durchzuführen. Oder es wird deutlich, dass die Umsetzung bis zum geplanten Release-Datum nicht mehr machbar ist. Oder es fehlen einfach noch Informationen, um hier und jetzt eine Entscheidung zu treffen. In jedem Fall entsteht Transparenz für alle Teilnehmenden.

• Close the Review: Auch ein Review braucht einen Abschluss. Es kann auch aufschlussreich sein, eine kurze Retro des Reviews durchzuführen, damit das nächste Review noch besser wird.

Um die verschiedenen Aspekte des Reviews auf dem Schirm zu haben, kann die Scrum Master:in diese Punkte explizit ansprechen:

• Welche neuen Anforderungen haben wir identifiziert?

• Haben sich die Prioritäten geändert?

• Gibt es neue Erkenntnisse, die sich auf die Schätzungen der Product Backlog Items oder den Release Plan auswirken?

• Ergeben sich Änderungen für die Architektur oder das Design des Produktes?

• Was könnte besser laufen in der Zusammenarbeit zwischen Stakeholdern und Scrum Team?

Zusammenarbeit mit Kunden. Maximierung des Werts, Erfolge sichtbar machen. Transparenz, Überprüfen und Anpassen. Wenn diese Elemente einer agilen Kultur bei euch im Sprint Review stattfinden, dann ist es richtig gut!

Beim Schreiben dieses Artikels habe ich mich an die Regeln und das Glossar der deutschen Scrum-Guide-Übersetzung gehalten.