Was macht eigentlich ein Product Owner?

2016 brachte der Regisseur Lars Kraume das Theaterstück “Terror” von Ferdinand von Schirach ins Fernsehen und die Zuschauer konnten darüber abstimmen, ob der für den Abschuss eines entführten Flugzeugs verantwortliche Major schuldig oder freigesprochen werden soll. Eine Versuchsanordnung, in der die deutschen Zuschauer mit mehr als 85 Prozent für einen Freispruch stimmten. Der verantwortliche Major muss sich zu Beginn des Theaterstücks entscheiden, ob er zusieht, wie das entführte Flugzeug in ein vollbesetztes Stadion gelenkt wird oder ob er es abschießt und zumindest die Zuschauer im Stadion rettet. Das Theaterstück beleuchtet Für und Wider und die moralischen Aspekte, die mit einer solchen Entscheidung einhergehen. Klingt spannend? Aber auch etwas überspitzt für einen Beitrag zur Rolle des Product Owners?

Schauen wir uns dazu Teile der Definition des Product Owner aus der aktualisierten Fassung des Scrum Guides (https://www.scrumguides.org/scrum-guide.html#product-owner) einmal an und klären, wie das Theaterstück und die Arbeit eines PO zusammenhängen:

“The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum team. (…)

The Product Owner is also accountable for effective Product Backlog management, which includes:

• Developing and explicitly communicating the Product Goal
• Creating and clearly communicating Product Backlog items
• Ordering Product Backlog items
• Ensuring that the Product Backlog is transparent, visible and understood

The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable. “

Accountability / Führungsverantwortung

Der wichtigste Begriff, der auch im Update des Scrum Guides eine größere Rolle als vorher spielt, ist der Begriff der “Accountability”, zu deutsch vielleicht am ehesten übersetzt mit dem Begriff “Führungsverantwortung”. Für den PO geht es darum, Verantwortung zu übernehmen und das nicht nur gegenüber dem Business oder dem Management, sondern vor allem auch für das Team, in dem er die oben genannten Aufgaben erfüllt. Mit der Erfüllung dieser Aufgaben, fällt es dem Team leichter, die Arbeiten zu übernehmen, für die sie “accountable” sind. Das heißt auch, dass der PO wie der Major aus Schirachs “Terror” eine große Verantwortung gegenüber anderen Menschen und vor allem dem Team und Stakeholdern übernehmen muss und Abwägungen und vor allem Priorisierungen treffen muss. Auch wenn dies manchmal einen sogenannten Trade-Off erfordert.

Oftmals macht sich dieser Trade-Off darin bemerkbar, dass zum Beispiel technische Features höher priorisiert werden, die aus Sicht des Teams eher eine Verschlechterung sind, aber von den Stakeholdern, die Einfluss auf den PO haben, als wichtiger und gut für das Produkt eingeschätzt werden. Hier muss der PO Stellung beziehen und sich überlegen, welche Interessen er verfolgen will und prüfen, was wirklich zur Verbesserung des Produktes und somit auch den Endkunden hilft.

Wie also kann ein PO diese Aufgaben erfüllen?

Grob gesagt könnte man die Aufgaben eines Product Owners auch mit den Oberbegriffen „Kommunikation“ und „Priorisierung“ betiteln. Am Ende führt das Zusammenspiel beider Bereiche zu einer Maximierung des Produktwertes.

Als erstes gilt es für den Product Owner zu klären: Was will ich mit meinem Produkt erreichen? Welche Ziele will ich damit verfolgen und welche Vision steht dahinter? Oder habe ich bestimmte Ziele vorgegeben bekommen, die das Produkt erfüllen muss? Wir haben gute Erfahrungen damit gemacht, in einem Visionsworkshop (natürlich auch remote) von einem Status Quo ausgehend in mehreren Schritten Ideen und Anforderungen abzuleiten und diese gemeinsam mit dem Product Owner und dem Team zu einem Zielbild zusammenzuführen. Die frühe Einbeziehung des Teams hilft auch hier, die Vision an alle Projektbeteiligten nicht nur zu kommunizieren, sondern auch gemeinsam zu gestalten – ganz im Sinne der Verantwortung des POs “Developing and explicitly communicating the Product Goal”. Während des laufenden Projekts ist es Aufgabe des POs, die Vision immer wieder zu prüfen und gegen die sich ständig ändernden Umstände abzugleichen.

Klar verständliche Product Backlogs für das Team

Um den Wert eines Produktes zu steigern, ist es wichtig, dass das beteiligte Team die einzelnen Anforderungen versteht und adäquat umsetzen kann. Demnach gehört es zu den Aufgaben des Product Owners, klar verständliche Product Backlog Items zu erstellen. In den meisten Fällen bestehen diese Backlog Items aus Epics mit darunterliegenden Tickets. Für klar kommunizierte Anforderungen innerhalb der Tickets verwenden wir Ticket-Guidelines, deren Basis für Neuanforderungen die Form der User Story gepaart mit eindeutigen und nachvollziehbaren Akzeptanzkriterien enthalten.

Wie im Beispiel aus dem Theaterstück ist eine zentrale Funktion des POs die Priorisierung. Welche Backlog Items sollen zuerst für einen neuen Sprint eingeplant werden? Welche Items zahlen auf die Produktvision ein und erhöhen den Business Value? Von welchem Feature haben meine Kunden den meisten Nutzen? Das sind nur einige Fragen, die vom PO beantwortet und betrachtet werden müssen. Keiner hat gesagt, dass es leicht sei, Product Owner zu sein!

Oftmals sind diese oberflächlich einfachen Fragen komplexer als sie auf den ersten Blick erscheinen. Denn beteiligte Stakeholder mischen sich unter Umständen ein und versuchen Einfluss zu nehmen. Kurzfristige Budgetkürzungen drohen oder der PO ist abhängig vom Business und hat gar keine Budgethoheit.

Und wie können wir als Dienstleister dabei unterstützen?

Hier können wir als Dienstleister in enger Abstimmung mit unseren Kunden große Erfolge verzeichnen, wenn wir einen sogenannten Proxy-PO auf unserer Seite etablieren. D.h. einer unserer Mitarbeiter erfüllt gemeinsam mit dem Kunden diese Rolle und kennt somit beide Seiten. Im Detail kann es so aussehen, dass sich der Proxy PO auf unserer Seite mit dem PO auf Kundenseite regelmäßig zusammensetzt, sie gemeinsam Storys schreiben, technisch evaluieren und gemeinsam priorisieren. Möglich ist auch, dass der Proxy PO freie Hand bekommt und nur die Anforderung der Vision kennt und alles dafür tut diese zu erreichen. In diesem Szenario wird der PO auf Kundenseite lediglich zu einem Stakeholder. Problem ist hier aber, dass ein Proxy PO niemals frei über das Budget verfügen kann.

Der Proxy PO sollte immer beratend zur Seite stehen und in enger Abstimmung beim Ausführen der Aufgaben supporten oder diese sogar übernehmen. Ausgestattet mit dieser Expertise und dem Vertrauen des Kunden, ist so eine Führung des Projekts ausgerichtet an der Produktvision äußerst erfolgsversprechend. Mit großer Macht kommt auch große Verantwortung und wie im Beispiel des Theaterstücks hat die Rolle des POs viel mit Abwägung und Analysevermögen zu tun. Es ist ein Weitblick erforderlich, der auch manchmal unangenehme Entscheidungen rechtfertigt, da sie auf das Produkt einzahlen. Projekterfolg wird maßgeblich durch die Rolle des POs beeinflusst.

Weitere Blogbeiträge zum Thema Scrum und agilem Arbeiten findet ihr hier