Welche Funktion hat ein Product Owner und was benötigt er/sie dafür?
Der Product Owner (häufig abgekürzt mit PO) ist eine Verantwortklichkeit im Kontext der agilen Entwicklung. Er oder sie vertritt die Interessen der Stakeholder, erarbeitet die Produktvision, definiert die Merkmale des Produkts und das Product Goal, baut das Product Backlog auf, setzt Prioritäten und sichert die Traceability zwischen Backlog und Produktvision.
In der Praxis wird die Position des Product Owners unterschiedlich verstanden. Man findet sowohl Business Analytiker ohne Entscheidungsbefugnis, die Stakeholder-Anforderungen aufnehmen, dokumentieren und dem Scrum-Team kommunizieren, aber auch Business Sponsoren, auf die der Business Case bzw. die Produktidee zurückgeht und die produktbezogene sowie finanzielle Entscheidungen treffen. Ist Product Ownership also eher eine operative Tätigkeit oder eine mit Verantwortung verbundene Managementaufgabe?
Definition im Scrum Guide von 2020:
Der Product Owner ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt. Wie dies geschieht, kann je nach Organisation, Scrum Team und Individuum sehr unterschiedlich sein. Der Product Owner ist auch für ein effektives Product‐Backlog‐Management ergebnisverantwortlich, das Folgendes umfasst: das Product Goal zu entwickeln und explizit zu kommunizieren, die Product‐Backlog‐Einträge zu erstellen und klar zu kommunizieren, die Reihenfolge der Product‐Backlog‐Einträge festzulegen und sicherzustellen, dass das Product Backlog transparent, sichtbar und verstanden ist. (Scrum Guide 2020)
Zentrales Arbeitsmittel des Product Owner ist das Product Backlog. Es spiegelt in hohem Maße die Entscheidungen des Product Owners wider. Sie betreffen den Inhalt und die Prioritäten der Product Backlog Items. Die Auswirkungen dieser Entscheidungen werden spätestens beim Review der Sprint-Ergebnisse bzw. der fertiggestellten Inkremente sichtbar. Voraussetzung für eine erfolgreiche Arbeit des Product Owners ist, dass alle Beteiligten innerhalb der Organisation seine Entscheidungen akzeptieren und respektieren. Dazu gehört auch, dass jeder, der Wünsche an das Produkt hat, der also das Product Backlog ändern oder erweitern möchte, den Product Owner kontaktieren muss. Da er/sie die Verantwortung für das Ergebnis trägt, muss er/sie von der Sinnhaftigkeit der Änderungswünsche überzeugt werden. Sollten die Änderungen so gravierend sein, dass das Sprint Goal unerreichbar wird, kann einzig und allein der Product Owner einen Sprint abbrechen.
„Wer ist mein Ansprechpartner, wenn ich als Stakeholder eine besondere Anforderung an das Produkt habe?“ „Wer kann mir als Entwickler genauer sagen, was der Grund für ein spezielles Backlog Item ist, damit ich wirklich verstehe, was dahintersteckt?“ – Die Antwort lautet: der Product Owner. Aber ist die Antwort immer so klar? Nur dann, wenn der Product Owner genau eine Person ist – kein Team und kein Entscheidungsgremium. Denn genau eine Person als Ansprechpartner bedeutet, kurze Kommunikationswege und die Chance, dass alle Produktentscheidungen transparent und nachvollziehbar werden.
Vermittler zwischen einem Entwicklungsteam und Product Owner
In großen Vorhaben, die mit mehreren Teams realisiert werden, wird die Forderung, dass der Product Owner genau eine Person sein soll, zum Problem. Der Product Owner hat in diesen Fällen für jedes einzelne Team selten mehr als ein paar Stunden pro Woche Zeit. Einige Organisationen haben sich deshalb dafür entschieden, Proxy Product Owner für jedes Team einzusetzen. Ihre Aufgaben sind:
Auch der Proxy Product Owner muss seine/ihre Arbeit an der Maximierung des Produktwerts ausrichten. Dazu muss er/sie wissen, wie Geschäfts- und Kundenbedürfnisse in wertstiftende Produkte umgesetzt werden können. Der klare Nachteil der Lösung: Die Kommunikationswege werden länger, Entscheidungen sind schwieriger nachzuvollziehen.
Auch wenn Proxy Product Owner im Einsatz sind, gilt jedoch: Der Product Owner bleibt in der Verantwortung. Im Scrum Guide steht dazu:
Der Product Owner kann alle genannten Arbeiten selbst durchführen oder die Umsetzungsverantwortung an andere delegieren. Unabhängig davon bleibt der Product Owner ergebnisverantwortlich.
Um Werte für die eigene Organisation und den Kunden zu schaffen, muss der Product Owner stets das Große und Ganze – den Geschäfts- und Lösungskontext – im Blick haben. Er/sie muss wie der Kunde denken, also Kundenprobleme erkennen und bewerten, aber auch Lösungen aufzeigen, die den Kunden begeistern. Das setzt analytisches Denken voraus. Gleichzeitig muss der Product Owner auch agil sein, indem er/sie die kontinuierliche Lieferung von Werten anstrebt. Dabei sind strategische Aspekte und die Machbarkeit in Einklang zu bringen. Und natürlich muss er/sie alles daran setzen „Waste“, also Arbeiten für den Papierkorb, zu vermeiden.
So vielseitig wie das Aufgabegebiet eines Product Owners, so umfangreich ist auch die Toolbox aus Methoden und Techniken, die er/sie dafür benötigt. Agile Arbeits- und Planungstechniken gehören ebenso dazu wie Führungs- und Kommunikationstechniken, sowie Techniken zur Ideen-, Lösungs- und Entscheidungsfindung. Quellen dafür sind agile Methoden, Business Analyse, Requirements Engineering, Produktmanagement und UX Design, um nur die wichtigsten zu nennen.
Hier ist eine kleine Auswahl, die lediglich einen Eindruck von der Spanne der benötigten Techniken und Methoden geben kann:
| Business Case | Ein Business Case bewertet Nutzen, Kosten und Risiken eines neuen Projekts. Der Business Case dient als Grundlage für die Genehmigung oder Ablehnung eines Vorhabens. |
| Business Model Canvas | Das Business Model Canvas ist ein in neun Segmente (Key Partners, Key Activities, Key Resources, Value Proposition, Channels, Customer Segments, Cost Structure, Revenue Streams) unterteiltes, wandfüllendes Plakat. Es wird zur strukturierten, interaktiven Entwicklung von Geschäftsmodellen im Team benutzt. |
| Collaborative Games | Mit kollaborativen Spielen sollen die Teilnehmer einer Erhebungsaktivität zur Zusammenarbeit ermutigt werden. Ziel ist es, ein gemeinsames Verständnis für ein Problem oder eine Lösung zu entwickeln. |
| Customer Journey Map | Eine Customer Journey Map hilft dabei, ein Unternehmen aus der Sicht der Kunden zu betrachten. Sie dient u.a. dazu, die Kundenbeziehungen zu analysieren und besser zu verstehen. |
| Elevator Pitch | Ein Elevator Pitch ist eine Kurzpräsentation, die die Vorteile einer Lösung in der Dauer einer Fahrstuhlfahrt auf den Punkt bringt. |
| Human-Centred Design | Human-Centred Design ist ein Ansatz zur Problemlösung, der vom beobachteten menschlichen Verhalten ausgeht. |
| Kano Modell | Das Kano Modell beschreibt den Zusammenhang zwischen der Erfüllung von Kundenanforderungen und der Kundenzufriedenheit. |
| Minimum Viable Product | Das Minimum Viable Product (MVP) ist die erste minimal funktionsfähige Ausprägung oder Iteration eines Produkts. Es dient dazu, ein schnelles Feedback vom Markt zu erhalten, mit dem Ziel, Fehlentwicklung und Fehlinvestitionen zu vermeiden. |
| Personas | Personas stellen Nutzer-Archetypen oder Prototypen für eine Gruppe von Nutzern dar. Personas zu entwickeln empfiehlt sich speziell dann, wenn ein Unternehmen keinen einfachen und günstigen Zugang zu den Nutzern hat. Die ausgeprägten Eigenschaften und das konkrete Nutzungsverhalten der Personas helfen bei der Entwicklung von Lösungen. |
| Problemanalyse und -definition | Die Problemanalyse dient dazu, nicht nur die Auswirkungen, sondern auch die Ursachen von Problemen zu erkennen. Jeder, der an einem Produkt mitarbeitet, von den Stakeholdern bis zu den Entwicklern, sollte die Ursachen eines Problems kennen – als ersten Schritt zu einer Produktvision. |
| Backlog Grooming / Refinement | Product Backlog Refinement (nach Scrum) ist der kontinuierliche Prozess zur Ausarbeitung der Backlog Einträge bis zur Umsetzungsreife in einem Sprint. |
| Product Roadmap | Die Product Roadmap beschreibt über einen Zeitraum (typischer Weise von einem Jahr), wie der Weg eines Unternehmens zur Realisierung seiner Vision aussieht. |
| Product Vision Board | Das Product Vision Board ähnelt dem Business Model Canvas. Es ist ebenfalls ein in mehrere Sektionen unterteiltes Plakat. Es dient der interaktiven Entwicklung einer gemeinsamen Vision des zu entwickelnden Produkts bzw. des Ziels der Produktentwicklung im Team. |
| Story Mapping | Eine User Story Map ordnet – ausgehend von der User Experience – User Stories in ein strukturiertes Modell ein, um das Big Picture der Anforderungen und damit die Funktionalität des zu entwickelnden Produkts zu verstehen. So wird eine ganzheitliche Release-Planung möglich. |
| Stakeholder Analyse | Die Stakeholder Analyse ist eine Technik, mit der vor Beginn eines Vorhabens alle Beteiligten, interessierte Personen und Interessengruppen sowie ihr Einfluss, ihre Beziehungen untereinander und ihre Ziele identifiziert werden. |
| Value Stream Mapping | Value Stream Mapping (VSM) ist eine Technik, die eingesetzt wird, um Wertströme innerhalb einer Organisation zu identifizieren und zu optimieren. Ziel dabei ist es, mit Blick auf die Schnittstellen von Organisationseinheiten, doppelte oder unnötige Arbeiten zu erkennen zu eliminieren bzw. zu minimieren |
