Gibt es hierzu Best-Practices oder Erfahrungen? Was ist aus Eurer Sicht besser?
2 Antworten
Hallo Maria, über diesen Punkt wird häufig diskutiert, weil der Name "Product Owner" für unterschiedlichste Rollen/Verantwortlichkeiten verwendet wird.
Scrum Theorie:
Die Verantwortlichkeit "Product Owner" ist kein Teamlead und nicht der Controller vom Team. Die Zusammenarbeit besteht also nicht darin alles in Frage zu stellen, was das Team behauptet und es selber besser zu wissen. Der Scrum Guide sagt, dass ein Backlog Item erledigt ist, sobald das Ziel des Backlog Items unter Berücksichtigung der Definition of Done erreicht wurde. Das kann also auch mitten am Tag innerhalb eines Sprints sein.
Das "Sprint Review" ist in erster Linie dafür da das Produkt zu inspizieren und Feedback zum Produkt zu geben. Das Review ist damit KEIN Abnahmemeeting.
Theorie in SAFe:
Hier gibt es nicht pro Produkt ein Product Owner, sondern pro Team (Team Product Owner), also deutlich mehr. Es gibt auch viele Ebenen über dem Team Product Owner (Produkt Management, Business Owner) welche die wichtigen Entscheidungen treffen. Hier wird der Team Product Owner als Proxy zu den Kunden definiert, meiner Meinung nach im krassen Gegensatz zu den agilen Prinzipien. Er wird also als Bottleneck definiert, der am besten die Kunden kennt (in Scrum würde man auf direkt Kommunikation setzen und das Team direkt mit den Kunden reden lassen). Zusätzlich wird ihm die Aufgabe gegeben, Backlog Items abzunehmen. Dies widerspricht der Selbstverantwortlichkeit des Teams. In diesem Framework ist es tatsächlich seine Aufgabe, die Einhaltung der Akzeptanzkriterien und der Definition of Done zu überprüfen.
Es gibt also beides. Die agilen Prinzipien sprechen ganz klar für die Definition von Scrum (also keine Abnahme durch den PO). Hast du ein Team, dem du nicht vertraust und auch zukünftig nicht vertrauen möchtest, dann kannst du natürlich so eine Pseude Teamlead Rolle/Verantwortlichkeit einführen, der/die allein für die korrekte Abnahme der Stories verantwortlich ist. Wenn diese Person dann mal ausfällt oder länger im Urlaub ist, wird es natürlich schwierig.
Scrum Theorie:
Die Verantwortlichkeit "Product Owner" ist kein Teamlead und nicht der Controller vom Team. Die Zusammenarbeit besteht also nicht darin alles in Frage zu stellen, was das Team behauptet und es selber besser zu wissen. Der Scrum Guide sagt, dass ein Backlog Item erledigt ist, sobald das Ziel des Backlog Items unter Berücksichtigung der Definition of Done erreicht wurde. Das kann also auch mitten am Tag innerhalb eines Sprints sein.
Das "Sprint Review" ist in erster Linie dafür da das Produkt zu inspizieren und Feedback zum Produkt zu geben. Das Review ist damit KEIN Abnahmemeeting.
Theorie in SAFe:
Hier gibt es nicht pro Produkt ein Product Owner, sondern pro Team (Team Product Owner), also deutlich mehr. Es gibt auch viele Ebenen über dem Team Product Owner (Produkt Management, Business Owner) welche die wichtigen Entscheidungen treffen. Hier wird der Team Product Owner als Proxy zu den Kunden definiert, meiner Meinung nach im krassen Gegensatz zu den agilen Prinzipien. Er wird also als Bottleneck definiert, der am besten die Kunden kennt (in Scrum würde man auf direkt Kommunikation setzen und das Team direkt mit den Kunden reden lassen). Zusätzlich wird ihm die Aufgabe gegeben, Backlog Items abzunehmen. Dies widerspricht der Selbstverantwortlichkeit des Teams. In diesem Framework ist es tatsächlich seine Aufgabe, die Einhaltung der Akzeptanzkriterien und der Definition of Done zu überprüfen.
Es gibt also beides. Die agilen Prinzipien sprechen ganz klar für die Definition von Scrum (also keine Abnahme durch den PO). Hast du ein Team, dem du nicht vertraust und auch zukünftig nicht vertrauen möchtest, dann kannst du natürlich so eine Pseude Teamlead Rolle/Verantwortlichkeit einführen, der/die allein für die korrekte Abnahme der Stories verantwortlich ist. Wenn diese Person dann mal ausfällt oder länger im Urlaub ist, wird es natürlich schwierig.
Das was im Scrum Guide dazu steht finde ich sehr passend: "The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed." Das heißt erstmal, dass im Scrum Review keine Übergabe der Ergebnisse oder Ähnliches von Developers an dem Product Owner stattfindet. Es ist eher eine Präsentation an die Stakeholder, also Menschen die Ausserhalb des Scrum Teams sind.
Es muss also vor dem Sprint Review schon Instanzen geben wo Developer mit Product Owner über den Stand der Stories reden und wo der Product Owner (als Vertreter der Kunden) Feedback gibt. In der Regel gehört diese Überprüfung der Stories in die Definition of Done. Stories können demnach nur geschlossen werden, wenn es zu dieser Überprüfung durch den Product Owner kam. Ob ich das "Abnahme" nennen würde? Ich weiß nicht, Abnahme klingt sehr Bürokratisch für mich. Das Ziel der Überprüfung durch Product Owner und Developers ist aus meiner Sicht weniger "Compliance" sondern eher eine Maßnahme damit der Kunde das bekommt was er braucht.
Und nun zu diesen ominösen "Instanzen" wie ich sie genannt habe. In einige Teams mit denen ich gearbeitet habe, gab es nach dem Daily immer wieder die Möglichkeit Dinge zu präsentieren wo die Developer Feedback vom Rest des Teams haben wollten. Diese Zeitslots wurden unter Anderem benutzt um Stories die aus Sicht der Developer fertig waren zu inspizieren. Wenn Developer und PO zufrieden waren, und die Stories damit alle Definition of Done Kriterien erfüllt haben, dann wurden diese Stories als Fertig markiert.
Und dann zurück zum Review Meeting: im Review Meeting sollten dann nur Stories gezeigt werden die schon Fertig sind. Sonst sind es ja keine "results". Das zwingt die Scrum Teams dazu sich auf Fertigstellung von Stories zu fokussieren. Darüberhinaus verwirren halbfertige Stories die Stakeholder, da sie oft als Fertig wahrgenommen werden. Danach ist es nicht verständlich warum dann noch an Dingen weitergearbeitet wird die schon längst fertig waren.
Ich hoffe, ich konnte dir mit meinen Ideen weiterhelfen!