Ist es sinnvoll im Sprint Review auch halbfertige Stories zu präsentieren? Was spricht dafür, was dagegen?
2 Antworten
Grundsätzlich bin ich der Meinung, dass nur komplett fertig gestellte Stories präsentiert werden sollten.
Es gibt aus meiner Sicht allerdings auch eine Ausnahme:
Wenn sich beim Umsetzen der Story im Sprint Fragen ergeben haben, die an Hand des halbfertigen Ergebnisses erst sichtbar werden, halte ich es für sinnvoll diese zu präsentieren und Feedback zur weiteren Umsetzung einzuholen.
Im Review geht es ja eben primär darum Feedback zur weiteren Entwicklung einzuholen und nicht (nur) um die Präsentation des Fortschrittes der Entwicklung.
Es gibt aus meiner Sicht allerdings auch eine Ausnahme:
Wenn sich beim Umsetzen der Story im Sprint Fragen ergeben haben, die an Hand des halbfertigen Ergebnisses erst sichtbar werden, halte ich es für sinnvoll diese zu präsentieren und Feedback zur weiteren Umsetzung einzuholen.
Im Review geht es ja eben primär darum Feedback zur weiteren Entwicklung einzuholen und nicht (nur) um die Präsentation des Fortschrittes der Entwicklung.
Die Erfahrung von Matthias teile ich. Letztendlich ist die Vorbereitung sowie Gestaltung des Sprint Reviews eine Aufgabe der Entwickler. In diesem Kontext hat sich im Sinne des gemeinsamen voneinander Lernens angeboten, auch halbfertige Stories zu besprechen. Das Sprint Review wurde dazu in zwei zeitlich ohne Pause aufeinander folgende Teile gesplittet: Ein Austausch über die fertigen Stories mit den Stakeholdern und dem Product Owner sowie ein zweiter Teil, wo die Stakeholder nur optional dabei waren, um den Stand der halbfertigen Stories (vorwiegend mit dem PO) zu besprechen. So wurde das agile Mindset sowie der Inspect und Adapt Prozess gefördert. So konnten auch wertvolle Informationen mit ins Sprint Planning genommen werden. Der Erfüllungsgrad des jeweils committeten Sprint Backlogs hatte sich dadurch bei den Teams verbessert.