Ein wertvoller Sprint Review (in diesem Blog von nun an als Demo bezeichnet) kann in drei Schritten aufgebaut werden. Er beginnt während der Sprint-Planungssitzung mit der Vereinbarung und dem Verständnis der User Stories im Sprint Backlog. Dann, während des Sprints, tauscht das Team ständig Ideen und Ergebnisse der Umsetzung der Story aus. Schließlich führen der Product Owner und der Rest des Teams den Stakeholdern die Stories während der Demo vor, um den gelieferten Wert zu zeigen und sich für Feedback zu öffnen.
Stellen Sie sicher, dass die Stories aus der Sicht eines Endbenutzers der zu liefernden Funktionalität formuliert werden. Dabei kann es sich um einen tatsächlichen Benutzer handeln, um ein System, das das erzeugte Ergebnis aufnimmt, oder um irgendeine andere Manifestation dessen, wer oder was das Ergebnis der Story nutzen wird.
Achten Sie auch darauf, dass die Akzeptanzkriterien klar sind. Auf diese Weise ist den Entwicklern klar, was sie bauen sollen, den Testern, was sie testen sollen und den Designern, was sie entwerfen sollen. Das hilft dem Product Owner, eine bessere Vorstellung davon zu bekommen, was in einer neuen/anderen User Story enthalten ist und was eventuell definiert werden muss. Es ist wichtig, dass jeder den Kontext versteht, in dem die Story "lebt". Welcher Teil des Systems wird berührt (vorzugsweise End-to-End, aber nicht immer möglich), welche Parteien sind von der Änderung betroffen, welche Voraussetzungen werden benötigt usw.
Planung für eine gute Demo
Während der Planungssitzung ist es unerlässlich, dass der Product Owner und der Rest des Teams die Stories verstehen, die aufgenommen werden sollen. Das hört sich selbstverständlich an, aber es kommt häufig vor, dass dies nicht der Fall ist. Die Stories könnten zu technisch sein, so dass der Product Owner nicht mitkommt, oder die Stories sind so komplex, dass es schwierig ist zu bestimmen, was getan werden muss.Gebäude für eine große Demo
Wenn während der Erstellung des Wertes jeder Story das gesamte Team in ständigem Kontakt über Zwischenergebnisse und getroffene Entscheidungen steht, kann jeder zum Wert beitragen und weiß, was das Ergebnis der Story sein wird. Es ist sehr wichtig, dass das gesamte Team den Product Owner einbezieht. Wenn der PO die Zwischenergebnisse sieht, kann er sich bereits ein Bild davon machen, wie das Ergebnis aussehen wird. Außerdem kann der PO Kontakt zu den Stakeholdern aufnehmen, die eine Meinung zu dem Ergebnis haben könnten, und bei Bedarf das Endergebnis an die Erwartungen anpassen.Eine wertvolle Demo abliefern
In der Demo sollte der Product Owner den Stakeholdern den Wert jeder einzelnen User Story, die geliefert wurde, präsentieren. Erläutern Sie also für jede Story, was sich aus Sicht des Endbenutzers geändert hat, und lassen Sie den Rest des Teams dies zeigen. Erläutern Sie auch, welche (Teil-)Funktionalität noch nicht fertiggestellt ist, wenn Stories noch nicht fertig sind. Bitten Sie den Endbenutzer oder andere Beteiligte um Feedback zu dem, was gezeigt wird.Fazit
Der Wert der Demo hängt weitgehend von der Zusammenarbeit des gesamten Teams ab. Wenn der Product Owner und der Rest des Teams zusammenarbeiten, um zu verstehen, was geliefert werden soll, und sich gegenseitig helfen, den größten Nutzen aus jeder gelieferten Story zu ziehen, wird die Demo zielgerichtet, wertvoll und unterhaltsam sein.Verfasst von

Marnix van Wendel de Joode
Unsere Ideen
Weitere Blogs
Contact
Let’s discuss how we can support your journey.



