Product Owner. Partner von Stakeholder & Team, verantwortlich für das Product Backlog und Product Goal.
Welche Funktion hat ein Product Owner und was benötigt er/sie dafür?
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?
Der Product Owner: eine Verantwortlichkeit nach Scrum
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)
Woran arbeitet ein Product Owner?
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.
Warum gibt es nur einen Product Owner?
„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.
Der Product Owner besitzt die Autorität zu entscheiden, was gebaut wird. Die Kehrseite der Medaille: Er/sie ist dem Erfolg eines Produkts uneingeschränkt verpflichtet.
Was ist ein Proxy Product Owner?
Vermittler zwischen einem Entwicklungsteam und Product Owner
- sicherstellen, dass die Entwickler die Elemente des Product Backlogs auf dem erforderlichen Niveau verstehen. Dazu vermittelt der Proxy Product Owner zwischen dem Product Owner und den Entwicklern,
- das Product Backlog pflegen, Product Backlog Items formulieren und ausprägen,
- Stories und Akzeptanzkriterien überprüfen und freigeben,
- Demo- und Review-Sitzungen leiten.
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.
So erstellen, verfeinern & priorisieren Sie als Product Owner das Backlog
Erfahren Sie hier mehr zu Agilität
mit objectiF RPM »
Welche Fähigkeiten braucht ein Product Owner?
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.
8 Product Owner Skills
1. Technisches Verständnis
2. Mut zur Vision
3. Strategisches Entscheidungsfähigkeit
4. Business-Analysefähigkeiten
5. Führungsqualitäten
6. Kommunikationsfähigkeit
7. Fähigkeit zur Interaktion mit Team & Stakeholdern
8. Lösungsorientiertes Denken
Techniken für Product Owner
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 |
Wertmaximierung in der Praxis
- Wie analysiert ein Product Owner nicht nur den Bedarf sondern schafft auch Innovation?
- Warum muss ein Product Owner nicht nur Business Insider sondern auch Entrepreneur sein?
- Was gehört alles zum Product Backlog Management?
Im Video erfahren Sie es.