9 von 10 Product-Ownern beklagen sich, dass ihr Kalender aus allen Nähten platzt.
Zur selben Zeit gleicht das Review einem Trauerspiel: Die Entwickler des Teams stellen Entwicklern anderer Teams den Fortschritt bei der Programmierung der Features vor, indem sie jeden Task in Jira detailliert erklären. Das Ergebnis: viel Gerede, wenig Erkenntnis und kein Grund für irgendwen außerhalb des Teams, diesen Termin ernst zu nehmen oder freiwillig zu besuchen.
Der Scrum Guide schreibt:
„Events werden in Scrum verwendet, um Regelmäßigkeit zu schaffen und die Notwendigkeit von Meetings, die in Scrum nicht definiert sind, zu minimieren.“
Damit dieses Versprechen von Scrum wahr wird, bedarf es einiges an Mut.
Viele befürchten:
- Das Team steht schlecht da, wenn das Produkt noch nicht lauffähig ist.
- Stakeholder nutzen das Review, um Druck zu machen oder Zusagen einzufordern.
- Das Team blamiert sich mit haltlosen Versprechen vor den Kunden.
Deshalb sprechen viele Product-Owner lieber mit jedem Stakeholder einzeln. Nicht, weil es effizienter ist, sondern weil es sich sicherer anfühlt. Das Ergebnis: Ihr Kalender platzt vor Abstimmungsterminen.
Das hat gleich mehrere negative Auswirkungen:
Entscheidungen werden immer wieder neu erklärt, Feedback wird nicht für alle sichtbar gemacht, und jeder bewertet den Fortschritt der Entwicklung unterschiedlich. Das führt unweigerlich zu Konflikten und wiederum zu mehr Abstimmungsterminen. Ein Teufelskreis.
Mit einem guten Sprint-Review entkommst du dieser Meeting-Hölle. Es bündelt Abstimmungen, schafft Klarheit für alle Beteiligten und reduziert genau die Meetings, die heute deinen Kalender verstopfen.
Diese drei Fragen helfen dir dabei:
- Wer sind die Stakeholder?
- Welcher Agenda folgen wir im Termin?
- Wie können wir alle miteinbeziehen?
Betrachten wir nun Frage für Frage ausführlich.
Los geht’s.
Frage #1: Wer sind die Stakeholder und wer sollte ins Sprint-Review eingeladen werden?
Ein Sprint-Review beginnt nicht mit dem Sprint-Review.
Es beginnt bereits mit den Fragen:
- Wer sind eigentlich die Stakeholder des Produkts?
- Wie können wir sie hilfreich einbeziehen?
Diese Fragen lassen sich einfach mit einer Stakeholder-Matrix beantworten.
Gehe dazu so vor:
- Liste alle Personen auf, die Interesse am Erfolg des Produkts haben oder Einfluss auf dessen Entwicklung ausüben.
- Ordne die Personen anschließend den passenden Kategorien der Matrix zu.
Wer sollte zum Sprint-Review eingeladen werden?
- Ich starte immer bei den „Promotoren“. Sie stellen große Kunden, Investoren, Manager, Vertriebsleiter oder wichtige Nutzer dar. Das sind die Personen, mit denen dein Team sich regelmäßig austauschen sollte, um Anforderungen an das Produkt zu erkennen und bestehende Annahmen über den Einsatz des Produkts zu überprüfen.
- Danach lade ich gezielt auch „Verteidiger“ ein. In der Regel handelt es sich hierbei um gewöhnliche Nutzer oder Projektmanager anderer Vorhaben.
- Die restlichen Stakeholder würde ich zunächst über andere Wege einbeziehen oder informieren, etwa indem ich Release-Notes veröffentliche, einen Newsletter versende oder sie einen Feedbackbogen ausfüllen lasse.
Dieser Schritt, also Stakeholder wirklich einzuladen, braucht viel Mut. Und ich will ehrlich mit dir sein: 9 von 10 Teams, die ich unterstütze, bringen diesen Mut nicht auf. Hinter all dem stecken meist dieselben Gedanken:
- „Wir haben noch nichts Vorzeigbares“,
- „Die kommen eh nicht“ und
- „Dafür ist es noch zu früh.“
Ich gebe ihnen dann immer recht. Damit das Review niemandes Zeit verschwendet und für uns keine peinliche Nummer wird, müssen wir es entsprechend gestalten.
Wir müssen uns daher die nächste Frage stellen:
Frage #2: Welcher Agenda folgen wir im Sprint-Review?
Im Sprint-Review ist der ROI der entscheidende Faktor.
Wenn sich Teams beklagen, dass niemand zum Review kommt, ist bei näherer Betrachtung der Grund dafür häufig schnell gefunden: Ihr Review liefert nicht genug Mehrwert für die investierte Zeit der Stakeholder. Der „Return on Time Invested“ ist zu gering.
Im Folgenden findest du eine bewährte Agenda für ein Sprint-Review, das weniger als 60 Minuten in Anspruch nimmt. Viele Teams vermeiden genau diese Agenda, weil sie Fragen und Entscheidungen provoziert:
- Willkommen: Das Scrum Team heißt die Stakeholder willkommen und stellt die Agenda vor.
- Vorstellung der Ziele: Der Product-Owner stellt die aktuellen Ziele des Produkts und des Sprints vor. Es geht darum, die Frage zu beantworten, inwiefern dieser Sprint den Wert des Produkts gesteigert hat und wie das Team dem Produktziel näher gekommen ist.
- Ausprobieren des Inkrements: Die Stakeholder probieren die wichtigsten Änderungen der neuesten Version des Produkts aus. Falls nötig, steht das Team für Rückfragen und Erklärungen bereit.
- Feedback zum Inkrement: Nachdem die Stakeholder die neue Version des Produkts ausprobiert haben, geben sie dem Scrum Team Rückmeldung zur Nutzbarkeit des Inkrements.
- Vorstellung von Marktveränderungen und Lieferterminen: Um ein vollständiges Bild des aktuellen Produkts zu erhalten, müssen auch Veränderungen im Umfeld des Produkts betrachtet werden. Beispiele hierfür sind Absatzzahlen, Veränderungen im Kundensegment, die Kostenstruktur, regulatorische Veränderungen und Liefertermine.
- Vorstellung des aktuellen Product-Backlogs: Nachdem der aktuelle Zustand des Produkts bekannt ist, gilt es, einen Blick auf den nächsten Sprint zu werfen. Der Product-Owner stellt dazu das Product-Backlog kurz vor, und gemeinsam mit den Stakeholdern wird überlegt, was ein lohnendes Ziel für den nächsten Sprint sein könnte.
Eine Anmerkung zu Marktveränderungen und Lieferterminen: Dieser Schritt fehlte in 99 % aller Reviews, die ich in meinem Leben besucht habe. Darin liegt allerdings auch die Antwort darauf, warum sich Vertriebsleiter, Manager oder die Geschäftsführung nicht ins Review verirren: Genau das interessiert sie.
Niemand hört freiwillig stundenlangen Präsentationen zu.
Deshalb sollten die Stakeholder aktiv einbezogen werden. Zum einen müssen sie Informationen erhalten, die ihre Arbeit erleichtern, etwa zur Marktsituation und zu Lieferterminen. Zum anderen müssen sie das Gefühl haben, dass ihre Anwesenheit dem Team weiterhilft.
Deshalb lautet die letzte Frage:
Frage #3: Wie können wir das Sprint-Review von einer reinen Präsentation in eine Working-Session verwandeln?
Hier drei Tipps:
- Das Sprint-Review sollte „zum Anfassen“ sein: Teile Tablets oder Handys an die Stakeholder aus, auf denen die neueste Produktversion zum Ausprobieren bereitsteht. Oder lass die Stakeholder ein neues Feature live am PC testen.
- Beziehe jeden Stakeholder ein: Bitte sie um Feedback. Lass sie ein mögliches Sprintziel formulieren oder Einträge des Product-Backlogs per Value-Estimation bewerten. Eine solche Working-Session erfordert einiges an Mut. Unerfahrene Product-Owner befürchten, sie könnten inkompetent wirken, da sie kein eigenes Sprintziel setzen können. Dem ist aber nicht so: Wir suchen nach neuen Gesichtspunkten.
- Stelle das Backlog vor: Allerdings nicht das Backlog in Jira mit 100 Einträgen, sondern wähle eine Darstellung, in der die Stakeholder auf einen Blick die mögliche Zukunft des Produkts erkennen können – etwa in Form einer Roadmap.
Hier ein Roadmap-Format, das ich in meinen „Professional Scrum Product Owner“-Trainings bespreche, zur Veranschaulichung:
Agilität ist im Wesentlichen eine Antwort auf das Problem, dass wir die Zukunft nicht perfekt vorhersagen können.
Scrum Teams akzeptieren das und tasten sich Schritt für Schritt vor – immer auf der Suche danach, wie sie das Produkt und ihre Arbeitsweise noch besser machen können.
Dieses Vorgehen sollte auch beim Review nicht aufhören. Deshalb zum Abschluss noch eine Frage:
Bonusfrage: Wie können wir unser Sprint-Review bis zum nächsten Mal verbessern?
Hier ein einfaches Vorgehen: das „Perfection Game“.
Es besteht aus diesen beiden Fragen:
- Auf einer Skala von 0 bis 10: Inwieweit hat dir dieses Sprint-Review geholfen, deine Aufgabe im Unternehmen zu erfüllen?
- Welche Verbesserungen sollten wir vornehmen, um von dir eine perfekte Punktzahl zu erhalten?
Damit bekommst du eine konkrete Rückmeldung, was im nächsten Sprint-Review besser gemacht werden kann, ohne viel Zeit zu investieren.
Das erfordert aber viel Mut: Du fragst nach Kritik, statt sie zu vermeiden.
Hast du diese vier Fragen bereits beantwortet?
Und suchst jetzt nach Wegen, Dich als Product Owner weiterzuentwickeln und zum Product Leader zu werden, der Verantwortung für den unternehmerischen Erfolg des Produkts übernimmt?
Dann wirf einen Blick auf das „Professional Scrum Product Owner – Advanced“-Training. Dieses Jahr auch als Online-Training.!