SCRUM kennt verschiedene Aktivitäten, die innerhalb eines Sprints einmal oder mehrmals zelebriert werden:
- Daily Scrum
- Sprint Planning (Teil 1 und 2)
- Sprint Review
- Sprint Retrospektive
- Backlog Refinement
Im Zusammenhang mit ein paar anderen Überlegungen stellte ich mir vor einiger Zeit die Frage, ob eigentlich eine dieser Aktivitäten wichtiger ist als die anderen.
Reflexartig habe ich erst einmal alle als gleich wichtig angesehen aber irgendwie kam mir das komisch vor, da wir ja z.B. beim Backlog Refinement eine solche Antwort nicht akzeptieren würden und immer dem Mantra folgen, dass es keine zwei identische Prioritäten gibt.
Also zwang ich mich dazu für mich eine Priorität der Aktivitäten festzulegen, was keine einfache Aufgabe war.
Ich halte z.B. die Retrospektive für äußerst wichtig, da sie einen der zentralen Punkte des inspect and adapt darstellt. Auch das Daily erscheint unersetzlich und ohne Planning wird es ja ziemlich schwer etwas abzuliefern.
Aber am wichtigsten erscheint mir die Sprint Review zu sein.
Das hat für mich damit zu tun, dass die Review der Punkt ist, an dem unsere Arbeit formal mit der Realität außerhalb des Entwicklungsteam konfrontiert wird und, dass die Review der zentrale Punkt ist, an dem die wichtigsten Stakeholder der Produktentwicklung zusammentreffen.
Daher habe ich mich noch einmal damit beschäftigt, wie andere die Sprint Review sehen.
Was sagt der Scrum Guide zur Sprint Review?
Am Ende eines Sprints wird ein Sprint Review abgehalten, um das [Produkt-]Inkrement zu überprüfen und das Product Backlog bei Bedarf anzupassen. Während des Sprint Reviews beschäftigen sich das Scrum Team und die Stakeholder gemeinsam mit den Ergebnissen des Sprints. Zusammen mit eventuellen Änderungen am Product Backlog während des Sprints bieten diese die Basis für die gemeinsame Arbeit an möglichen neuen, den Wert des Produkts steigernden Punkten. Beim Sprint Review handelt es sich um ein informelles Meeting, keinen Statusreport. Die Vorführung des Inkrements ist als Anregung für Feedback und die Basis für die Zusammenarbeit gedacht.
(…)
Das Sprint Review beinhaltet die folgenden Elemente:
Die Teilnehmer, bestehend aus dem Scrum Team und wichtigen Stakeholdern, die vom Product Owner eingeladen werden.
Der Product Owner erklärt, welche Product Backlog-Einträge “Done” sind, und welche nicht.
Das Entwicklungsteam stellt dar, was während des Sprints gut lief, welche Probleme aufgetaucht sind, und wie es diese Probleme gelöst hat.
Das Entwicklungsteam führt die “Done”- Arbeiten vor, und beantwortet Fragen zu dem Inkrement.
Der Product Owner stellt den aktuellen Stand des Product Backlogs dar. Er gibt bei Bedarf eine aktualisierte Vorhersage eines Fertigstellungstermins, auf der Basis des Entwicklungsfortschritts.
Alle Teilnehmer erarbeiten gemeinsam, was als nächstes zu tun ist, so dass das Sprint Review wertvollen Input für die kommenden Sprint Plannings liefert.
Es erfolgt eine Begutachtung, ob sich durch die Marktsituation oder den möglichen Produkteinsatz neue Erkenntnisse über die wertvollsten nächsten Schritte ergeben haben.
Anschließend werden Zeitplan, Budget, die potentiellen Eigenschaften sowie die Markterwartungen für das nächste zu erwartende Produkt-Release überprüft.
Das Ergebnis des Sprint Reviews ist ein überarbeitetes Product Backlog, das die möglichen Product Backlog-Einträge für den kommenden Sprint enthält. Das Product Backlog kann auch umfassend umgearbeitet werden, um neue Chancen zu nutzen.
Und
an anderen Stellen wird immer wieder das Mantra wiederholt:
Remember that a Sprint Review is much more than just a demo.
weiterhin findet sich immer wieder
Key decisions that were made during the iteration/sprint (this may include technical, market-driven, requirements, etc, and can be decisions made by the team, the product owner, the customers, or anyone else) (siehe)
Oana Juncu
einen spannenden Blickwinkel brachte einmal mehr Oana Juncu ein:
The point is that anyone needs to be proud of her work. In Agile Development the demo is a visible proof that work done is great , has added value, delights users and deserves to be proud of.
The key is to know clearly what is the result expected – so people can be proud of. This is the reason why sharing the clear shape of the demo in a bigger picture of the vison of the product ( let’s call it your product Story – or “Vision” if you like the Visionary Side of Product Development) is deadly important.
Manche gehen sogar soweit, von Demo driven Development zu sprechen, mit der Review als zentralem Element.
Warum das für uns besonders wichtig ist
Wir entwickeln kein eigenes Produkt sondern wir entwickeln Software im Auftrag unserer Kunden. Für jedes Team sollte der Kontakt jedes Sprint-Ergebnisses mit den effektiven Nutzern das wichtigste sein aber im Gesamtbild betrachtet ist die Review der Punkt, an dem alle Stakeholder (im Idealfall auch einige Nutzer) auf das Sprint-Ergebnis treffen. Während des Sprints kommunizieren wir mit einzelnen Stakeholdern aber die Review stellt das Sprint-Ergebnis in ein Gesamtbild.
Im zweiten Teil des Artikels beschreibe ich dann, wie ich mir eine ideale Review vorstelle.
PS: Das interessante an der Priorisierung im Backlog Refinement ist, dass das Ergebnis immer nur die Sichtweise zum aktuellen Zeitpunkt darstellt und schon beim nächsten Refinement anders aussehen kann. Vielleicht ist das auch bei der Frage der wichtigsten SCRUM Aktivität so.