Alles wurde fertig entwickelt, und mit etwas abendlicher Arbeit und ein paar Kompromissen bei der Qualität konnte man tatsächlich alles liefern, was im Sprint enthalten war. Im Review stellt man die entwickelten Features vor, die Entwickler zeigen die Storys, an denen sie gearbeitet haben. Es werden die Akzeptanzkriterien durchgegangen und am Ende jeder Story wird gefragt, ob das so in Ordnung ist. Dann nimmt der Product Owner die Story ab, und damit ist bestätigt, dass sie umgesetzt wurde. Das Ganze wird formal dokumentiert – im Ticketing oder im Wiki – und am Ende gibt es ein Protokoll der Veranstaltung.
Das ist praktisch für das Team: Diese Stories sind fertig, bis auf Bugfixes und neue Features wird man von ihnen wenig hören. Endlich etwas geschafft.
Den Sprint abnehmen?
Aber der Scrum Guide sieht das aus gutem Grund anders. Das Review wird dort explizit als „informelles“ Meeting beschrieben; eine Abnahme durch den Product Owner gibt es nicht. Auch nicht durch die Stakeholder.
Es wird über die umgesetzte Arbeit geredet – aber dort berichtet der Product Owner selbst und hört nicht wie ein Kunde bei der Produktpräsentation dem Team zu. Es wird präsentiert, aber da geht es nicht um die Abnahme, sondern um ein gemeinsames Bild darüber, was die nächsten Schritte sind. Reicht uns das Feature so? Haben wir vielleicht schon erstes Feedback, dass wir etwas ergänzen sollten? Hat sich gezeigt, dass eigentlich eine andere Variante mehr Wert als die gewählte erzeugen kann?
Den Blick in die Zukunft richten
Dabei geht es nicht um die Beurteilung der vergangenen Arbeit; das wäre Zeitverschwendung, denn an der Vergangenheit lässt sich nichts mehr ändern. Es geht darum herauszufinden, ob der Sprint etwas für die jetzt kommende Arbeit geändert hat.
Die Aufgabe des Teams ist nicht, die Features „zu liefern“ und damit auch die Verantwortung für sie abzugeben. Die Aufgabe des Teams ist, zu jedem Zeitpunkt das Nützlichste und Wichtigste für Nutzer und Produkt zu tun. Deshalb stellt sich nicht die Frage nach Akzeptanz der Features, sondern nur die Frage „Gibt es andere nützlichste und wichtigste Dinge, die man jetzt tun sollte?“
Welche Möglichkeiten es gibt, das durch entsprechendes Feedback herauszufinden und welche Fehler einem dabei unterlaufen können, zeigt euch Martin in seinem Beitrag 4 Tipps für besseres Feedback in Sprint Reviews.
[smartblock id=“7056″]Unsere Serie Agile Missverständnisse
Agile Missverständnisse
Agile Methoden haben eine klare Intention: Sie wollen die Wertschöpfung bei der Entstehung von Software steigern. Sie bieten zu diesem Zweck gleich einen ganzen Stapel von Werten, Prinzipien und Methoden an, die dabei unterstützen.
In der Praxis sind die Intentionen hinter diesen Werkzeugen oft nicht mehr so klar, und manchmal gehen sie ganz verloren; die Methode bleibt, mit ihren Umständlichkeiten und Haken, nur ohne den erwünschten Effekt. Über diese Art von agilen Missverständnissen will ich hier berichten – und darüber, wie man mit ihnen umgeht.
Schreibe einen Kommentar