Projekt Beschreibung

Was ist nötig, damit ein Sprint Review gut funktioniert? Wieso kommen die Stakeholder nicht dazu? Wir zeigen dir in diesem Beitrag: So klappt das Sprint Review!

Das sagt der Scrum Guide

Das Sprint Review ist das wohl am häufigsten missverstandene Event in Scrum. Fast alle Teams, die ich bislang unterstützt habe, machen hier die gleichen Fehler. Das äußert sich dann darin, dass das Sprint Review als „Demo“ oder „Abnahmemeeting“ verwendet wird. Im Scrum Guide ist das Review folgendermaßen definiert:

Während des Events überprüfen das Scrum Team und die Stakeholder, was im Sprint erreicht wurde und was sich in ihrem Umfeld verändert hat. Auf der Grundlage dieser Informationen arbeiten die Teilnehmenden gemeinsam daran, was als Nächstes zu tun ist. Auch kann das Product Backlog angepasst werden, um neue Möglichkeiten wahrzunehmen. Das Sprint Review ist ein Arbeitstermin, und das Scrum Team sollte vermeiden, es auf eine Präsentation zu beschränken.

Erfolgreiche Formate

Das Sprint Review sollte also eine kollaborative Arbeitssession sein. Es geht um die intensive Interaktion mit den Stakeholdern, nicht um die passive Akzeptanz von Ergebnissen. Schon gar nicht, wenn diese frontal vorgetragen werden. PowerPoint ist in Sprint Reviews verboten!

Ein gutes Sprint Review sollte die folgenden Elemente beinhalten:

  1. Der Product Owner heißt alle Teilnehmer, insbesondere aber die Stakeholder, willkommen. Er ruft allen die Produktvision wieder ins Gedächtnis und fokussiert dabei auf den Wert des Produkts. Das heißt, er zeigt das „Big Picture“.
  2. Der Product Owner zeigt Produkt- und Sprintziel. Er erwähnt auch, ob das Ziel erreicht wurde, oder nicht. In manchen Fällen erklärt er auch das „Warum“, aber eigentlich ist das an dieser Stelle gar nicht so wichtig.
  3. Dann gibt der Product Owner an das Entwicklungsteam ab. Dieses zeigt kurz und knapp (wir reden von wenigen Minuten, nicht von Stunden), was im Produkt jetzt neu ist. Alles, was im Sprint nicht vollständig erledigt wurde (also „Done“ ist), wird auch nicht gezeigt. Dieses kurze Zeigen könnte man „Demo“ nennen. Allerdings geht es hier nur um ein kleines Element von zehn Minuten, nicht um das gesamte Event.
  4. Dann beginnt der eigentliche Spaß. Die Stakeholder dürfen das Produktinkrement ausprobieren! Sie benutzen es, berühren es, spüren es. Mit diesem Gefühl für das Produkt sind sie in der Lage zu beurteilen, ob ihnen das gefällt, was sie da in Händen (oder am anderen Ende der Maus) halten. Die Entwickler beobachten, machen sich Notizen und unterstützen bei Bedarf. Wenn neue Anforderungen entdeckt werden, oder ein Stakeholder die Reihenfolge im Product Backlog verändern möchte, kümmert sich der Product Owner um diese Anliegen.
  5. Der Product Owner und die Stakeholder inspizieren gemeinsam das Produkt Backlog und den Effekt, den die gerade gesammelten Erkenntnisse darauf haben. Wenn er dies als wertvoll erachtet, verändert der Product Owner das Product Backlog.
  6. Am Ende dankt der Product Owner allen für ihren Input und beendet das Event.

Dieser Ablauf ist nicht durch Scrum vorgeschrieben. Ich persönlich finde ihn aber sehr hilfreich.

Die Abnahme

Auch zur formellen Abnahme der Arbeitsergebnisse des Entwicklungsteams ist wenig im Scrum Guide definiert. Das Sprint Review ist der letztmögliche Zeitpunkt für den Product Owner, um die Ergebnisse abzunehmen. Mit Sicherheit aber eine der schlechtesten Optionen, denn dann erfährt der Product Owner zum selben Zeitpunkt wie seine Stakeholder, was im Sprint wirklich fertig wurde. Außerdem sorgt die Hinauszögerung der Abnahme dafür, dass im Korrekturfall Mehraufwand für die Entwickler entsteht, die folgende Features schon auf der implementierten Lösung aufgesetzt haben und sich erneut in den Code hineindenken müssen.

Erfahrene Product Owner machen ihre Abnahmen daher während des Sprints. Im Regelfall ein Product Backlog Item nach dem anderen, immer dann, wenn das Team eines davon als „fertig“ deklariert. Da der Product Owner auf täglicher Basis mit dem Team arbeitet, sollte das in den wenigsten Fällen ein Problem darstellen.

Scrum sagt nichts zur Abnahme der Ergebnisse durch den Endkunden oder die Stakeholder. Klar ist lediglich, dass der Product Owner hier verantwortlich ist, nicht das Entwicklungsteam. Du wirst in deinem Kontext also eine eigene Lösung definieren müssen. Dies ins Sprint Review zu verlagern ist zwar möglich, aber meist keine gute Idee. Transparenz geht dadurch verloren, dass jeder „gut aussehen“ möchte und man nicht ehrlich die Fakten auf den Tisch legt, wenn dadurch die Abnahme oder sogar die Bezahlung in Frage gestellt wird. Als Product Owner sollte man auch versuchen, die formale Abnahme komplett von Meetings zu entkoppeln. Stattdessen sollten KPIs (Key Performance Indicators) dazu herhalten. Wenn man den primären Werttreiber kennt, dann kann man die Abnahme der Ergebnisse automatisiert knüpfen. Wenn beispielsweise die Erhöhung der Vertriebszahlen um 10 Millionen Euro der Grund für die Produktentwicklung ist, dann kann man messen, ob diese erreicht wurde. Dann ist auch egal, welche Features von wo angefordert wurden: Wenn die Verkaufszahlen nicht steigen, hat der Product Owner seinen Job nicht gut gemacht. Andererseits ist es herzlich egal, ob der ursprüngliche Plan oder bestimmte „Gates“ eingehalten wurden, wenn die Verkaufszahlen in die Höhe schießen. Kurz gesagt: Es macht mehr Sinn, das reale Ergebnis zu messen, als den Weg dorthin.

Fazit

Das Sprint Review wird sehr häufig falsch durchgeführt, nämlich als „Abnahme“ oder „Demo“. Im Ergebnis macht das Event keinen Spaß und Stakeholder bleiben ihm fern. Organisiert es als kollaborative Arbeits-Session und verlagert Abnahmen heraus, dann sind eure Ergebnisse im Regelfall erheblich besser.

Hast du Fragen? Dann nimm gerne Kontakt mit uns auf. Wir unterstützen dich auch gerne bei der Analyse deines eigenen Sprint Reviews.