Sprint Review als Lernevent!

Sprint Review in Scrum
Von Sebastian Schneider // 02.02.2017 // 0 Kommentare

Das Sprint Review ist das vorletzte Event im agilen Framework Scrum. Zuvor haben bereits die Sprint Planung und das Daily Scrum stattgefunden. Nach dem Sprint Review folgt die Sprint Retrospektive

Das Sprint Review bietet die Möglichkeit das Produkt zu inspizieren und anzupassen. Dabei sollte das Sprint Review nicht als einfache Präsentation verstanden werden, sondern als ein Lernevent, in dem das Feedback der Stakeholder maximiert wird. Damit der Kundenwert noch besser verstanden wird, und klar ist, was die einzelnen Stakeholder wünschen.

Übersicht über das Sprint Review

Das Sprint Review in Scrum ist das Meeting, in dem das Team vorstellt, was es in diesem Sprint geleistet hat. Es ist damit eines der Scrum Events, welches das agile Prinzip der Transparenz sehr stark unterstützt. Ziel des Sprint Reviews ist es, ein funktionierendes Produktinkrement den Stakeholdern, Endnutzern und anderen Interessenten erlebbar vorzustellen. Das Sprint Review ist allerdings mehr, es ist ein Lernevent und sollte nicht als "einfache Demo" verkommen.

Scrum Guide deutsch

Scrum Guide

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

Im folgenden Video zu Scrum findet das Sprint Review Meeting seinen Platz. Schaue es dir gleich einmal im Explainer Style an.

Grundlagen zum Sprint Review

Das Sprint Review folgt einem recht einfachen Ablauf. Es ist wichtig, dass gerade bei inhaltlichen Diskussionspunkten nicht abgeschweift wird. Der Scrum Master moderiert hier, wenn nötig. Die Einladung zum Sprint Review kann gerne direkt vom Product Owner kommen, ist aber keine Pflicht.

Durch die Wiederholung deiner Sprints (Iterationen) betrachtest du in jedem Sprint Review ein Inkrement, welches auf dem vorherigen aufsetzt.

Input, Ablauf und Output des Sprint Reviews

Thema

Inhalt

Input für das Sprint Review

  • Die erledigte Arbeit, die während des Sprints entstanden ist.

Ablauf innerhalb des Sprint Reviews

  • Der Product Owner erklärt welche Einträge im Sprint abgenommen wurden und welche nicht.
  • Das Entwicklungsteam beschreibt kurz, vor welchen Herausforderung es gestanden ist und wie diese gelöst wurde.
  • Das Entwicklungsteam stellt die fertigen Product Backlog Items vor und beantwortet Fragen dazu.
  • Der Product Owner gibt Information zum Product Backlog, Fortschritt des Produktes und Daten zu Releases
  • Die gesamte Gruppe bespricht, was als nächstes sinnvoll in der Umsetzung ist, damit das Sprint Review wertvollen Input für den nächsten Sprint liefert.
  • Betrachten von Marktgegebenheiten und wie damit umgegangen werden kann, um das Wertvollste weiterhin zu erstellen.

Output der Sprint Planung

  • Durchgesehenes Product Backlog
  • Die nächsten wahrscheinlichen Product Backlog Items, die umgesetzt werden.

Dauer

  • Das Sprint Review findet für einen einmonatigen Sprint für 4 Stunden statt.
  • Je nach Produkt, den Product Backlog Items und weiteren Rahmenbedingungen kann die Läge variieren.

Dysfunktion: Wir haben aber nichts zu zeigen!

Ein häufiges Argument in Sprint Reviews ist "wir haben nichts zu zeigen". Wenn Sie dieses Aussage auch hören, dann ist die erste Frage nach dem Warum. Oft liegt das Problem darin begraben, dass die Teams vorher sequentiell gearbeitet haben und nun dieses sequentielles Vorhaben nur 1:1 auf die kürzen Sprints nur aufgeteilt wird. Hier sollten Sie einen Blick auf die Art der Product Backlog Items werfen und auch einmal auf das Produkt einen Blick zu werfen - macht das Sinn, dieses tatsächlich agil zu entwickeln?

Dysfunktion: Es werden immer alle Tickets durchgegangen

Das Sprint Review ist ein informelles Meeting und kein Statusmeeting. Hier soll erreicht werden, dass Sie Feedback bekommen und Zusammenarbeit fördern. Der Product Owner ist zwar die finale Instanz, die über Abnahme entscheidet, aber das muss nicht am Ende und nur im Sprint Review entschieden werden. Zudem ist es absolut in Ordnung sich auf die wichtigsten Themen zu konzentrieren, die (den Stakeholdern) gezeigt werden.

Eine gute Agenda für das Sprint Review erstellen

Ein Sprint Review soll ein Erlebnis sein und die Teilnehmer begeistern und ein gutes Gefühl geben. Beim Sprint Review soll Feedback erzeugt und nächste Schritte bestimmt werden. Und dazu müssen Sie im Sprint Review etwas zeigen können, was auch wert ist zu zeigen: Mehrwert für die Teilnehmer. Über die Anzahl deiner Sprints kann dir der Scrum Master helfen, die Agenda Stück für Stück zu verbessern. Das ganze Team kann und darf hier natürlich helfen.

1.
Begrüßung

Im Sprint Review geht es um das Produkt, also sollte der Product Owner sich auch nicht die Gelegenheit nehmen lassen, zu diesem Termin eine kurze Begrüßung aussprechen, die Menschen willkommen heißen und das Event zu eröffnen. Alles was nicht direkt zum Produkt gehört, wird im Vorfeld kurz gefasst.

2.
Sprint Ziel prüfen

Haben wir in diesem Sprint das Sprint Ziel erreicht? Mit der Beantwortung dieser Frage haben Sie schon wichtiges geschafft: Den Fokus zu setzen und gleich den Eindruck zu geben, wie erfolgreich der Sprint war. Wenn das Sprint Ziel "Live setzen der neuen SAP Eingabemaske" war und Sie diese Frage mit ja beantworten können, dann gibt das dem Event eine gute Richtung.

3.
Fertige Arbeit zeigen

Jetzt werden Product Backlog Items vorgestellt. Dabei gilt: Man muss nicht immer alles vorstellen! Oft reicht es, wenn die Teilnehmer wissen, das Sprint Ziel ist erreicht und die wichtigstens Product Backlog Items, die auf das Thema einzahlen, erlebbar sind. Dabei stellt das Entwicklungsteam die PBI bitte immer selbst vor. Zur Orientierung kann der Product Owner die zu zeigenden PBIs im Vorfeld an die Teilnehmenden schicken, dann ist die Erwartungshaltung klar. Es kann sich zum Beispiel im Daily Scrum herausstellen, was konkret gezeigt werden soll, aber auch zu jedem anderen Zeitpunkt. Es sollte nur vorher klar sein.

4.
Feedback einholen

Nun wissen Sie, ob das Sprint Ziel erreicht worden ist, welche Product Backlog Items enthalten sind und jetzt kann das Entwicklungsteam damit beginnen, tatsächlich etwas zu demonstrieren. Das ist der Hauptteil des Sprint Reviews und sollte allen Beteiligten eine Menge an Möglichkeiten für das Erlebnis und das Feedback einräumen. Es gehört zur Wertschätzung und zum Zeigen der Kompetenz, dass das Entwicklungsteam direkt und selbst zeigt. Gibt es schwierige Stakeholder kann und sollte der Product Owner das entsprechende Geschick besitzen, das Entwicklungsteams zu unterstützen, wenn das nötig ist. Denken Sie daran, dass der Product mehr im Bereich "was" (Produkteigenschaften) die Hoheit haben sollte, das Entwicklungsteam im "wie" (konkret umgesetzte Funktionalität).

5.
Erlebnisse teilen

In einem weiteren Teil der Sprint Review Agenda wird kurz über die Erlebnisse und möglicherweise auch Probleme gesprochen, denen das Team bei der Produktentwicklung begegnet ist. Dabei liegt der Fokus nicht auf der Reflexion des eigenen Prozesses, als viel mehr auf dem des Produktes. Der Prozess wird mit den Teilnehmer in der Sprint Retrospektive besprochen. Zudem kann der Product Owner noch einmal den Stand und Fortschritt aus Produktsicht, Releases und voraussichtlicher Prognose für Termine auf Basis der empirisch ermittelten Velocity zeigen.

6.
nächste PBIs

Wir gehen auf das Ende des Sprint Reviews zu. Dort geht es darum, dass der Product Owner die nächsten Product Backlog Items vorstellt, die wahrscheinlich umgesetzt werden. Das passiert meistens auf Basis des Sprint Reviews, der Erlebnisse und der Erkenntnisse. Wenn Ihr Produkt weniger starke Schwankungen auf dem Markt besitzt, dann kann es sein, dass dieser Abschnitt kurz ausfällt oder nur selten adressiert wird. Am Ende sollte auf jeden Fall klar sein, welches die nächsten wahrscheinlichen Product Backlog Items sind.

Wie viel Zeit benötigt das Sprint Review?

Der Scrum Guide gibt eine Timebox von vier Stunden für einen einmonatigen Sprint für das Sprint Review an. In meinem Artikel zum Meeting Overhead beleuchte ich die Zeiten vom Sprint Review noch einmal genauer. Dein Scrum Master hilft dir hier Klarheit zu schaffen.

Je nach Team und ggf. einer Scrum Skalierung kann der Bedarf nach mehr Zeit für ein Sprint Review steigen. Gerade wenn Teams sehr motiviert sind und erledigte Arbeit gerne zeigen möchten. Was bei einem Team meist recht problemlos funktioniert, kann im größeren Kontext schwierig werden. Gerade wenn du mehrere Teams hast (die alle an einem Produkt arbeiten), sollten sich die Teams so abstimmen, dass (z.B. durch Marktstände oder ähnliches) die Feedbackmöglichkeit für die Stakeholder maximiert wird.

Abnahme von Product Backlog Items

Gerade wenn Teams immer viel zeigen wollen, aber natürlich auch sonst, gilt die Regel, dass Product Backlog Items jederzeit vom Product Owner "abgenommen" werden. Wenn du so möchtest, ist das Sprint Review natürlich nur der letztenmögliche Zeitpunkt, bei dem das geschehen kann. Das trägt ein gewisses Risiko, es lohnt sich deshalb fertige Product Backlog Items schon vorher abzunehmen. Wenn das Entwicklungsteam etwas fertiggestellt hat, kann es zum Product Owner gehen und darum bitten.

Der Product Owner nimmt die Product Backlog Items in der Regel immer ab, wenn die Definition of Done erfüllt ist und die Akzeptanzkriterien ebenso Anwendung gefunden haben. Das ist ein Entwicklungsprozess, spielt sich aber mit der Teamreife meistens ein.

Über die Sprints hinweg sollte die Abnahme von mal zu mal besser werden. Wenn du entdeckst, dann auch noch mehreren Sprints immer noch keine Verbesserung eingetreten ist, dann schaue doch mal nach der Größe deiner Product Backlog Items und ebenso nach der Art deiner Arbeit.

Dysfunktion: Alles was wir nicht schaffen, ziehen wir immer in den nächsten Sprint!

Häufig findet man das folgende Verhalten zwischen dem Sprint Review und der Sprint Planung. Zum einen wird im aktuellen Sprint oft nicht alles geschafft, zum anderen wir immer alles in den nächsten Sprint überführt. Kommt Ihnen das bekannt vor? In solch einer Situation sollten Sie sich einmal fragen, wie volatil ihr Umfeld ist. Dann lohnt sich auch die Frage, ob diese Situation jemanden stört. Wenn ja, wen? 

Lerne im Sprint Review

Im Sprint Review kannst du sehr viel über dein Produkt lernen. Klar, dazu musst du natürlich ein Produkt entwickeln und auch entsprechend Scrum korrekt einsetzen 🙂

Lerne die Benutzung des Produktes durch deine Kunden kennen

  • Gehe offen mit dem Ergebnis um, erzeuge Transparenz gegenüber der Kunden
  • Wie gehen die Kunden mit dem Inkrement um? Was kannst du bei der Benutzung lernen? Was ist für dich neu, so wie die Kunden es benutzen?
  • Achte darauf, wie die Reaktion der Kunden bei der Benutzung ist. Ist es ein Apple-Feeling? Oder handelt es sich eher um ein "ist okay" Feeling?
  • Frage als Product Owner bei Aussagen zum Produktinkrement immer nach, wie Aussagen konkret gemeint sind, vielleicht verbergen sich neue Anforderungen dahinter.

Lernen Sie neue Formen des Sprint Reviews

Natürlich sind eingeschwungene Agenden gut für die Planung. Aber ab und an wirken sie auch mal dröge. Wie kannst du neuen Wind in das Sprint Review bringen? Wenn es um's Lernen geht, dann ist es wichtig, dass du auch maximal lernen kannst. Dazu solltest du (wenig überraschend) die folgenden Dinge vermeiden.

  • Es darf nicht klar sein, dass deine neue Idee eh einen Erfolg bedeutet. Dann lernst du (für Neuigkeiten) recht wenig.
  • Es darf nicht klar sein, dass deine neue Idee eh einen Misserfolg bedeutet. Dann lernst du ebenso wenig neues.

Lernen funktioniert also dann immer gut, wenn du im Sprint Review für das Format auch mal etwas ausprobierst, was ein gutes Lernpotential birgt. Das muss sich natürlich nicht nur auf das Format beschränken.

Einige Möglichkeiten und Fragen:

  • Wie kannst du den Ort verändern? Versuche doch mal dein Sprint Review an einem anderen Ort zu machen, der zu deinem Produkt passt!
  • Wie kannst du das Feedback weiter erhöhen? Kannst du produktfremde oder abteilungsfremde Personen spontan mal ansprechen und um Feedback bitten? 
  • Wie sieht der Product Owner die Erreichung des Sprint Ziels? Wie das Entwicklungsteam? Sind beide einer Meinung?
  • Ermutigen Sie die Stakeholder dazu, das Produkt zu erleben. Das Sprint Review in Scrum ist genau der richtige Platz das zu tun.
  • Erklären Sie kurz als Entwicklungsteam, was alles fertig geworden ist und starten Sie dann mit der Vorstellung des Produktinkrements.
  • Gibt es neue Erkenntnisse vom Markt? Kann der Product Owner hier neue Einsichten geben? Dann lohnt sich auch hier ein paar Minuten am Ende des Sprint Reviews zu investieren.

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

>