Offizielle Abnahme von Arbeiten im Sprint Review – Ja oder Nein?

Einige Teams nutzen das Sprint Review als Möglichkeit zur Abnahme der in diesem Sprint fertiggestellten Product Backlog Items durch den Product Owner oder die wichtigsten Stakeholder.

Grundsätzlich sollte ein Sprint Review nicht von einem Team genutzt werden, um die Arbeit vom Product Owner abnehmen zu lassen. Das Team und der Product Owner sollten schon während des Sprints so eng zusammenarbeiten, dass das Team ohnehin weiß, was der Product Owner von ihrer Arbeit hält.

„Keine Überraschungen” ist meine 1. Regel für das Sprint Review

Es ist vollkommen akzeptabel, wenn ein Product Owner die Arbeit des Teams für ein bestimmtes Product Backlog Item nicht annimmt. Allerdings sollte das Team schon vorher wissen, dass das so kommen wird.

Die Teammitglieder sollten nicht in ein Sprint Review hinein marschieren und große Anerkennung für ihre Arbeit erwarten, nur um dann völlig unerwartet Beschwerden zu ernten.

Kann ein Sprint Review offiziell für die Abnahme genutzt werden?

Wenn ein Kunde einen Anbieter beauftragt, ein Produkt für ihn zu entwickeln, fungiert idealerweise jemand im Unternehmen des Kunden als Product Owner. In diesem Fall kann es in Ordnung sein, dass Features im Sprint Review abgesegnet werden. Trotzdem bleibe ich dabei, dass es keine Überraschungen im Sprint Review geben sollte.

Auch wenn der Product Owner des Kunden dem Team während des Sprints Feedback gibt, ist es möglich, dass er mit einer offiziellen Abnahme warten muss, bis die anderen Stakeholder die Chance hatten, sich zu der Arbeit zu äußern.

Ein einfaches Beispiel

Ein einfaches Beispiel: Meine Tochter fragte mich letztens, ob sie an einem Schulausflug teilnehmen könne. Ich sagte, ich hätte kein Problem damit, aber – dreimal dürfen Sie raten – wir müssten erst noch ihre Mutter fragen. Der Grund dafür war, dass meine Frau für diesen Zeitpunkt schon andere Pläne für die Familie gehabt haben könnte, von denen ich noch nichts wusste.

Und die Abnahme in einem echten Projekt?

Das ist eine Alltagssituation für Product Owner bei Entwicklungsaufträgen. Auch wenn dem Product Owner, der täglich mit dem Team interagiert, gefällt, wie ein Feature gebaut wurde, muss er sich unter Umständen trotzdem vergewissern, dass die Stakeholder, die er oder sie repräsentiert, auch dieser Meinung sind. Natürlich könnte man behaupten, dass der Product Owner einfach zu ihnen gehen und sie fragen könnte. Das kann aber sehr unpraktisch sein und wird daher am besten einfach im Sprint Review erledigt.

Bei solchen Entwicklungsaufträgen stellt der Kunde aber nicht immer einen Product Owner zur Verfügung. Häufig zahlt der Kunde dafür, dass sich der Vertragspartner um alles kümmert.

Der Kunde ist natürlich trotzdem der eigentliche Product Owner. Der Kunde wird letzten Endes die Entwicklungsarbeit akzeptieren oder ablehnen. Er möchte aber nicht tagtäglich mit diesen Dingen „belästigt” werden. Die Lösung ist dann typischerweise, dass der Anbieter einen Product Owner aus seinem eigenen Unternehmen stellt.

Und in diesem Fall können also vor dem Sprint Review keine Product Backlog Items akzeptiert bzw. abgenommen werden. Der eigentliche Product Owner (aus dem Unternehmen des Kunden) ist nicht genug verfügbar und involviert, um öfter etwas abnehmen zu können.

Sicherlich kann das Team eine vorläufige Zustimmung von ihrem eigenen Product Owner während des Sprints bekommen. Der wahre Product Owner aus dem Unternehmen des Kunden kann im Sprint Review aber letztlich eine ganz andere Entscheidung treffen.

Die endgültige Antwort hängt, wie so oft, von dem Kontext der jeweiligen Situation ab. Und daher muss ich sagen, dass ich mir keine großen Gedanken darum mache, wenn die offizielle Abnahme von Arbeiten im Sprint Review geschieht. Trotzdem bleibe ich dabei, dass es im Sprint Review keine Überraschungen geben sollte.Tun Sie das, was für Sie am besten geeignet ist. Hauptsache, die Teammitglieder wissen schon vor dem Review, was auf sie zukommt.

Dieser Text stammt aus dem Blog von Mike Cohn und wurde von uns ins Deutsche übersetzt.

Product Owner Zertifizierung

=> Werde Certified Scrum Product Owner mit einem unserer Trainings!

Velocity-orientiertes Sprint Planning

=> Vorteile und Nachteile von velocity-orientiertem Sprint Planning

Wann sollte die Reihenfolge on Items geändert werden?

=> Hier sind 5 gute Gründe, warum man ab und an die Reihenfolge von Items im Sprint anpassen sollte.