Was ist ein Product Owner?

Die Rolle des Product Owners (kurz: PO) ist im Scrum Guide (wie alles andere auch) sehr knapp beschrieben. Einerseits bedeutet das für Dich große Freiheiten bei der Ausgestaltung dieser Scrum Rolle. Andererseits kann das für Dich als Neueinsteiger einschüchternd wirken. Weil vielleicht nicht genau klar ist, was die Aufgaben und Verantwortlichkeiten eines Product Owners sind. Wenn Dir dann kein erfahrener Scrum Master zur Seite steht und Du auch keine Product-Owner-Kollegen in Deinem Unternehmen hast, kann das dazu führen, dass Deine Rolle als Scrum PO von Dir selbst und anderen missverstanden wird.

In diesem Artikel habe ich deshalb einmal alle grundlegenden Aufgaben und Verantwortlichkeiten des Product Owners für Dich zusammengestellt und zu allen wichtigen Punkten, die im Scrum Guide zu finden sind, einige klärende Worte festgehalten. Sie sollen Dir dabei helfen, Dich in Deiner neuen Rolle als Product Owner zurechtzufinden und Dir die eine oder andere Stolperfalle ersparen, die auf Dich warten wird.

Im (deutschsprachigen) Scrum Guide findest Du einen wichtigen Satz über die Verantwortlichkeit des Product Owners:

Der Product Owner ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt.

Das bedeutet, dass Du als Product Owner dafür sorgen musst, dass Dein Scrum Team sich um die richtigen bzw. wichtigsten Dinge kümmert. Du sorgst also dafür, dass sich der Wert Eures Produktes kontinuierlich verbessert. Allerdings verliert der Scrum Guide keinerlei Wort darüber, was genau der „Wert des Produktes“ eigentlich sein soll. (Was natürlich auch schlichtweg nicht möglich ist, da Wert oder Nutzen je nach Produkt eine ganz andere Bedeutung hat.)

Im Englischen existieren zwei unterschiedliche Begriffe für das deutsche Wort Verantwortung: Zum einen Responsibility und zum anderen Accountability. Diese Entsprechung gibt es im Deutschen so nicht, weshalb der deutschsprachige Scrum Guide an manchen Stellen von umsetzungsveranwortlich (responsible) und ergebnisverantwortlich (accountable) spricht.

Es ist wichtig, dass Du Dir dieses Unterschieds als Product Owner bewusst bist. Denn als Scrum PO bist Du ergebnisverantwortlich und nicht umsetzungsverantwortlich für die Wertsteigerung des Produktes. In erster Linie bedeutet das, dass Du nicht alles selbst tun musst (und sollst), um den Wert des Produktes kontinuierlich zu steigern. Nichtsdestotrotz bist Du aber verantwortlich für das Ergebnis, das aus der gemeinsamen Arbeit Eures Scrum Teams entsteht.

Den Wert eines Produktes zu bemessen, kann auf viele unterschiedliche Arten erfolgen. Das Wichtigste dabei ist ein gemeinsam geteiltes Verständnis innerhalb Eurer gesamten Organisation zu erzielen, was Wert bedeutet. Das erreichst Du als Product Owner natürlich nur durch eine intensive Kommunikation mit Deinen Stakeholdern.

Wenn beispielsweise Projekte mit einem Produkt umgesetzt werden, dann entstehen dadurch automatisch Konflikte darüber, was Kundenzufriedenheit bedeutet. Projektleiter werden der Ansicht sein, dass die Zufriedenheit des aktuellen Kunden wichtig ist, während Du als Product Owner wahrscheinlich die Zufriedenheit aller Bestandskunden im Blick hast. Und dann sprechen alle über Kundenzufriedenheit, meinen damit jedoch vollkommen unterschiedliche Dinge.

Selbst dann, wenn ein einheitlicher Begriff – in diesem Fall Kundenzufriedenheit – genutzt wird, um den Wert des Produktes zu bemessen, wird dieser nicht immer von allen gleich verstanden.

Zur grundsätzlichen Problematik, wenn Produkte in Projekten genutzt werden, erfährst Du mehr in meinem Artikel Warum das Denken in Projekten Dein Produkt zerstört.

Einen Ausweg aus dieser Situation bieten klare Metriken, auf die sich Deine Organisation gemeinsam geeinigt hat.

Evidence-Based Management (EBM) kann sehr hilfreich für Dich und Deine Organisation sein, wenn es darum geht, den Wert Eures Produktes oder Services klar zu messen. Besonders interessant für Dich als Product Owner ist hier natürlich die Key Value Area Current Value und die dazugehörigen Metriken. (Natürlich kann auch der Fall eintreten, dass je nach Ausgangslage und Situation Metriken aus anderen Key Value Areas relevanter sind.)

Das wichtigste Werkzeug für Dich als Scrum PO ist Dein Product Backlog. Damit das Scrum Artefakt seinen Zweck erfüllt, bist Du als Product Owner verantwortlich (accountable) für ein effektives Product Backlog Management. Daraus resultieren vier wichtige Aufgabenfelder für Dich.

Das Produktziel ist seit dem Update des Scrum Guides im November 2020 ein fester Bestandteil des Product Backlogs. Neben dem Sprintziel und der Definition of Done ist es eines der drei Scrum Commitments.

Es ist wichtig, dass Dein Product Backlog stets nur ein einziges Produktziel verfolgt, da es sonst zu Zielkonflikten kommen kann.

Die Möglichkeiten, ein Produktziel zu formulieren, sind natürlich vielfältig. Es gibt jedoch zwei Ansätze, die besonders kompatibel mit dem Produktziel in Scrum sind:

Das Schreiben von Product Backlog Einträgen ist das Daily Business eines jeden Product Owners. Meistens haben sie die Form eines User Story, aber es gibt viele andere denkbare Möglichkeiten, die Anforderungen und Wünsche Deiner Stakeholder festzuhalten. (Beispielsweise mit Hilfe von Job Stories.)

Da Dein Product Backlog ein lebendes Artefakt ist und sich beständig verändert, benötigen die Backlog-Einträge eine kontinuierliche Pflege. Diese Pflege findet im Product Backlog Refinement statt, das Du gemeinsam mit allen Mitgliedern des Scrum Teams regelmäßig durchführst.

Als Product Owner musst Du also keineswegs ganz allein dafür sorgen, dass Product Backlog Einträge erstellt und überarbeitet werden. Du kannst (und solltest) hier auf die Hilfe & Unterstützung Deiner Entwickler und Deines Scrum Masters bauen. (Trotzdem bleibst Du ergebnisverantwortlich dafür, dass dies geschieht.)

Product Backlog Einträge entstehen natürlich nicht aus dem Nichts. Damit ist das Stakeholder Management einer Deiner zentralen Aufgaben als Product Owner. Um herauszufinden, was die Wünsche, Anforderungen und Bedarfe Deiner Stakeholder sind, kannst Du als Product Owner beispielsweise Kundeninterviews durchführen oder auf viele verschiedene Tests & Experimente zurückgreifen.

Bei all dem solltest Du als Product Owner jedoch eines nicht vergessen:

Es ist nicht Deine Aufgabe als Scrum Product Owner, immer alle Wünsche zu erfüllen und alle Stakeholder (immer) glücklich zu machen. Es ist Deine Aufgabe, die besten Entscheidungen für das Produkt zu treffen.

Die dritte Aufgabe des Scrum Product Owners ist die Priorisierung des Backlogs. In erster Linie ergibt sich diese Priorisierung natürlich aus Deinem Produktziel. Aber es wäre nicht realistisch zu glauben, dass das Tagesgeschäft keinen Einfluss auf diese Priorisierung hätte. Als Scrum PO hast Du diverse Stakeholder, die Anforderungen an Dein Produkt haben, die nicht zwangsläufig im Einklang mit Deinem Produktziel sind.

Damit Du Deiner Verantwortlichkeit als Product Owner wirklich nachkommen kannst, muss Dich Deine Organisation auch dazu ermächtigen.

Im Scrum Guide findest Du dazu zwei erhellende Textstellen:

For Product Owners to succeed, the entire organization must respect their decisions.

und

Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.

Es geht also nicht darum, dass alle Deine Stakeholder ihre Anforderungen einfach bei Dir „abkippen“ und es Deine Aufgabe als Product Owner ist, daraus eine schöne Reihenfolge zu basteln, damit nach Möglichkeit alle zufrieden sind. Sondern diejenigen, die die Reihenfolge des Backlogs ändern möchten, müssen Dich als Product Owner überzeugen. (Erfahrungsgemäß ist jedoch in den meisten Organisationen Ersteres der Fall.)

Arbeite gemeinsam mit Deinem Scrum Master daran, Deine Verantwortlichkeit als Product Owner in Eurer Organisation zu schärfen. Denn um Deine Rolle wirklich zum Leben zu erwecken, braucht es vor allem Zeit und (viel) Überzeugungsarbeit.

Damit Dein mächtigstes Werkzeug auch seinen Zweck erfüllen kann, ist es natürlich wichtig, dass Deine Stakeholder wissen, wo sie es finden können, wie es aufgebaut ist und grundsätzlich verstehen, wie es funktioniert. Am besten erreichst Du das, indem Du es als Product Owner bei jeglicher Kommunikation mit Deinen Stakeholdern verwendest. Das gilt ganz besonders für die Sprint Review, die dazu dient, Deinen Stakeholdern einen Ausblick auf die kommende Arbeit Deines Scrum Teams zu bieten.

Im besten Fall sind Deine Stakeholder selbständig in der Lage, das Product Backlog zu finden und zu verstehen, wenn sie Fragen über die nächsten Schritte der Produktentwicklung haben, ohne dabei auf Dich zurückgreifen zu müssen.

Auch hier kannst (und solltest) Du auf Deinen Scrum Master zurückgreifen, der Dich bei Deinen Product Owner Aufgaben unterstützen soll.

Wie Du siehst, sind die Aufgaben und Verantwortlichkeiten eines Product Owners sehr umfangreich und vielfältig. Je nach Kontext kann das bedeuten, dass Du alleine gar nicht in der Lage sein wirst, all diese Dinge selbst zu erledigen. Das gilt natürlich ganz besonders für den Fall, wenn Du Product Owner in mehreren Scrum Teams bist, die alle am gleichen Produkt arbeiten (beispielsweise in Form eines Nexus).

Allerdings ist das auch gar nicht notwendig, da Du Aufgaben und Verantwortlichkeiten an andere Teammitglieder delegieren kannst:

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

Ich hoffe, ich konnte Dir die vielfältigen Aufgabenfelder eines Product Owners mit diesem Artikel ein wenig näher bringen. Solltest Du noch Fragen, Ideen, Anregungen oder Kritik zu den Inhalten des Artikels haben, schreib mir gerne einen Kommentar unten auf dieser Seite. Ich freue mich über Feedback jeglicher Art und bin gespannt auf Deine Sichtweise!