Sprint Review: Wie Product Owner aus einer Demo einen Arbeitstermin machen

Kommt dir der folgende Ablauf des Sprint Reviews bekannt vor?

Als du den Raum für das Sprint Review betrittst, sind die Entwickler klar von den Stakeholdern zu unterscheiden. Die Entwickler sitzen links am lang gezogenen Konferenztisch und die Stakeholder rechts. Du nimmst am Fuße des Tisches Platz. Der Scrum Master sitzt dir gegenüber am Kopf und eröffnet das Meeting mit einführenden Worten. Danach präsentiert das Entwicklungsteams seine Arbeit. Erst nach einiger Zeit wird das Wort an dich gerichtet und du wirst aufgerufen, die User Stories abzunehmen. Zu diesem Zeitpunkt siehst du zum ersten Mal das Inkrement.

Bild von Campaign Creators auf Unsplash

Wenn du jetzt mit dem Kopf nickst und das ändern möchtest, dann ist dieser Beitrag für dich.

Bei meiner eigenen Arbeit als Product Owner und meiner jahrelangen Arbeit mit Scrum Teams muss ich leider das Fazit ziehen, dass die beschriebene Situation eher die Regel als die Ausnahme darstellt. Hier mein bewährtes Rezept, wie Product Owner das Sprint Review zu einem gemeinschaftlichen Arbeitstermin machen und nicht zu einer Demonstration, Präsentation oder Abnahme verkommen lassen.

Der Zweck des Sprint Reviews in Scrum ist die Lenkung der Produktrichtung auf der Grundlage von Feedback und gemeinsamen Verständnis.

Im Grunde genommen ist es ein strategisches Planungsmeeting. Es wird das Ergebnis des Sprints überprüft und künftige Anpassungen festgelegt. Um diesen Zweck zu erfüllen, hat es sich für mich bewährt, dass das Sprint Review die folgenden 4 Elemente beinhaltet:

• Product Owner lädt wichtige Stakeholder ein
• Stakeholder und Scrum Team überprüfen gemeinsam das Ergebnis des Sprints
• Besprechung der Veränderungen im Produktumfeld und Vorstellung des Product Backlogs
• Teilnehmer erarbeiten gemeinsam, was im nächsten Sprint zu tun ist

Hier die Schritte im Detail:

Product Owner lädt wichtige Stakeholder ein

Der Erfolg des Sprint Review hängt maßgeblich von den richtigen Teilnehmern ab.

Als Product Owner solltest du hier nichts dem Zufall überlassen. Du bist der Gastgeber dieses Termins. Lade vorab die nötigen Stakeholder aktiv zum Termin ein. Die richtigen Stakeholder sind die Personen, die maßgeblich Interesse und Einfluss auf den Erfolg des Produkts und somit auf deine Arbeit haben. Vergiss dabei die Kunden und Nutzer nicht. Als guter Gastgeber eröffnest du den Termin. Du dankst alle für ihr Erscheinen und erklärst noch einmal den Zweck des Sprint Reviews. Zum Schluss stellst du deine Vision für die Zukunft des Produkts vor.

Für Product Owner ist das Sprint Review der wichtigste Termin im Sprint. Er unterstützt dich dabei, die Richtung für das Produkt zu finden und vorzugeben.

Stakeholder und Scrum Team überprüfen gemeinsam das Ergebnis des Sprints

Als nächsten Punkt auf der Agenda stellst du das aktuelle Sprint-Ziel vor und erklärst wie dieses auf das Product-Ziel einzahlt. Im Anschluss daran erklärst du, welche Product-Backlog-Einträge in diesem Sprint fertiggestellt wurden und wie sie das Sprint-Ziel realisieren.

Nun kommt ein Fehler, den ich am häufigsten in der Praxis beobachte.

Die Entwickler stellen nun im Detail die fertige Arbeit vor und beantworten Fragen zum Inkrement der Stakeholder. Dadurch verkommt das Sprint Review mehr zu einer Präsentation und Demonstration und beraubt dich somit um Feedback zur Nutzbarkeit des Produkts aus erster Hand. Mach diesen Fehler nicht! Lade die Stakeholder lieber ein, die aktuelle Version des Produktes hier und jetzt selber zu testen. Wenn dein Produkt beispielsweise über eine Webseite zu erreichen ist, dann teile Tablets aus, damit die Stakeholder es live testen können. Bitte die Entwickler das Feedback der Stakeholder aufzunehmen.

Unerfahrene Product Owner begehen häufig noch einen weiteren Fehler, den du vermeiden solltest.

Der Product Owner nimmt im Sprint Review die Product-Backlog-Einträge ab. Das Sprint Review sollte niemals als Barriere zur Lieferung von Wert angesehen werden! Wenn euer Entwicklungsprozess eine Abnahme verlangt, dann führe diese vorab durch. Zum Beispiel kannst du nach dem Daily Scrum das Scrum Team fragen, ob du schon fertige Einträge ausprobieren kannst.

Durch das Inspizieren der aktuellen Version des Produkts im Sprint Review stellst du sicher, dass alle Beteiligten das gleiche Verständnis über den tatsächlichen Zustand des Produkts haben. Diese Transparenz bildet das Fundament, um belastbare Entscheidungen aus Aussagen über die Zukunft des Produkts zu treffen.

Besprechung der Veränderungen im Produktumfeld und Vorstellung des Product Backlogs

Ein Produkt existiert nicht in einem Vakuum.

Um eine ganzheitliche Sicht auf das Produkt zu erhalten, hat es sich bewährt, im Sprint Review auch das Umfeld des Produkts zu betrachten. Die Begutachtung der Marktsituation und mögliche Produkteinsätze beleuchten das Umfeld des Produkts genauso wie die Vorstellung von aktualisierten Zeitplänen, des Budgets oder potenziellen Kundenwünschen und Kundenanfragen. Als Product Owner musst du diesen Teil des Reviews nicht zwingend übernehmen. Beispielsweise kannst du auch die Kollegen des Vertriebs oder der Marktforschung bitten, die Daten zu präsentieren.

Um das Produktumfeld vollständig zu beleuchten, stellst du zum Schluss noch den aktuellen Stand des Product Backlogs vor. Verliere dich dabei aber nicht zu sehr in Details. Bei der Vorstellung geht es eher um einen groben Überblick über die Einträge, welche aktuell im Product Backlog oben stehen. Es kann auch hilfreich sein, dass du eine aktualisierte Vorhersage von wahrscheinlichen Ziel- und Lieferterminen auf der Basis des Entwicklungsfortschritts gibst. Ein Burn-Down-Chart kann dir helfen, schnell die wesentlichen Prognosen zu zeigen.

Jetzt sollte sich ein umfangreiches Verständnis bei allen Beteiligten über die aktuelle Situation des Produkts eingestellt haben und du kannst zur Beantwortung der wichtigsten Frage des Sprint Review übergehen: In welche Richtung sollte sich das Produkt nun entwickeln?

Teilnehmer erarbeiten gemeinsam, was im nächsten Sprint zu tun ist

Erfolgreiche Product Owner wissen, dass sie jeden wichtigen Stakeholder davon überzeugen müssen, dass sie seine Rahmenbedingungen verstehen und bemüht sind, das Produkt in eine Richtung weiterzuentwickeln, die diese Restriktionen berücksichtigen.

Mein Geheimtipp lautet hierfür:

1. Bitte jeden Stakeholder auf der Basis des bereits Gesehenen und Gehörten ein Ziel für den nächsten Sprint vorzuschlagen, welches aus seiner Sicht den größten Mehrwert für das Unternehmen liefert.
2. Falls die Ziele sehr unterschiedlich sind, leite eine Diskussion darüber an, welches dieser Ziele das wertvollste im Hinblick auf die Erreichung des Product-Ziels ist. Alternativ kann es auch hilfreich sein, ein übergeordnetes Ziel zu suchen, welches alle Vorschläge vereint.

Die gemeinsame Erarbeitung, was als Nächste zu tun ist, liefert dem Scrum Team wertvollen Input für das kommenden Sprint Planning und häufig bereits einen guten Kandidaten für ein initiales Sprint-Ziel.