Kaum ein agiles Team kommt ohne die Product Owner Rolle aus. Doch was ist ein Product Owner genau, welche Aufgaben hat er, welche Verantwortung und welchen Herausforderungen muss er/sie sich im Alltag stellen?
In diesem Artikel lernen Sie alles über diese wichtige Rolle. Diese Kapitel warten auf Sie:
- Product Owner Definition
- Gibt es Product Owner nur in Scrum-Teams?
- Product Owner Aufgaben
- Verantwortung der Product Owner Rolle
- Qualifikation: Was muss ein Product Owner können?
- Was ist „Product Backlog-Management“?
- Metriken zur Messung von Produktnutzen
- Herausforderungen für Product Owner
- Zusammenfassung
Los geht’s.
Product Owner Definition
Der Scrum Guide definiert: Der Product Owner ist dafür verantwortlich, den Wert des Produktes zu maximieren, das aus der Arbeit des Entwicklungsteams entsteht. Wie dies geschieht, kann je nach Organisation, Scrum-Team und Einzelpersonen stark variieren.
Gibt es Product Owner nur in Scrum-Teams?
Die Rolle des Product Owner kommt ursprünglich aus Scrum. Aber viele agile Entwicklungsteams haben jemanden, der die damit verbundenen Aufgaben wahrnimmt – auch wenn sie nicht nach Scrum arbeiten.
In Extreme Programming, einem anderen agilen Ansatz neben Scrum, gibt es beispielsweise die Rolle eines „On-Site Customers“ oder eines „Customer Proxy“ – also jemandem, der gegenüber den Developern die Kundensicht vertritt und dabei aber selbst Teil des Produktentwicklungsteams ist.
Product Owner im Kontext des agilen Teams. Die Rolle ist ein fester Teil davon und hat gleichermaßen die Sicht nach innen ins Team und nach außen zu den Stakeholdern.
Die Notwendigkeit dafür leuchtet schnell ein: Die meisten agilen Teams befassen sich mit innovativen Lösungen. Dabei sind sie oft von der Entwicklung, Weiterentwicklung und Aufrechterhaltung, bis hin zur Ablösung, komplett für „ihr“ Produkt verantwortlich. Sie brauchen also eine Person, die sich darum kümmert, dass diese Arbeit von Anfang an in die richtige Richtung geht. Das kann der Product Owner sein.
Product Owner Aufgaben
Die Rolle des Product Owner soll sicherstellen, dass das Produkt:
- den Markt bedient und Lösungen für vorhandene oder gar neu geweckte Nachfrage bietet
- dem Wettbewerb wenigstens standhält, oder besser: ihm voraus ist
- die Stakeholder und vor allem die Endkunden möglichst glücklich macht – aber natürlich nur gegen vertretbaren Aufwand und Kosteninvestitionen sowie ohne, dass die Wunschliste der Anforderungen ins Unendliche wächst
- Lösungen bietet, die wirklich sinnvoll und nützlich für die Kolleg:innen sind gegen einen vertretbaren Aufwand (gilt für interne Produktentwicklungen, etwa für andere Abteilungen in der eigenen Organisation)
- möglichst bald gewissen Zielvorstellungen entspricht, die mit Stakeholdern abgestimmt und dem Entwicklungsteam bekannt sind, bestenfalls eines, womit sich alle identifizieren können
- in einem bestimmten Zeitrahmen möglichst weit fortgeschritten in der Entwicklung ist, eventuell in Form von abgestimmten, schrittweisen Zwischenergebnissen
- Quick-Wins erzeugen kann, damit notwendige Liquidität für die Weiterentwicklung herrscht
- eigenen und äußeren Qualitätserwartungen entspricht
Um dieser sicherzustellen, sind wichtige Aufgaben des Product Owner im Detail:
Wichtige Aufgaben des Product Owner
1) Ziele und Vision entwickeln
- Ziele setzen und verfolgen: Product Owner müssen die größeren Ziele setzen und langfristig im Blick behalten. Die Developer hingegen kümmern sich um die iterative Umsetzung auf technischer Ebene.
- Produktvision entwickeln: Sie sollten eine Produktvision als langfristigen Nordstern mit Stakeholdern entwickeln und mit dem Team besprechen. (Ein Beispiel: „Die App „BestDoc“ ist eine Plattform zur Arztsuche, -bewertung und Terminbuchung am Smartphone – für Personen, die auf der Suche nach den besten Ärzten in der Region sind.“ Es kann aber auch ein Slogan sein oder etwas besonders Mitreißendes / Motivierendes.)
2) Stakeholder früh und häufig einbinden
- Ein Product Owner ist „Stakeholder-Versteher“, mit dem Ziel, ihre Interessen zu wahren, aber auch aktiv damit umzugehen und gegenüber dem Team gegebenenfalls zu filtern.
3) Übergeordnete Planung vornehmen
- Iterationen vorausplanen: Auf zeitnaher Ebene immer bereits die nächsten 1-3 Iterationen inhaltlich vorbereiten und mit einer groben Vorstellung für deren Zielsetzungen ans Team herantreten.
- Release-Pakete planen: Übergeordnete Zielsetzung und die richtige Planung; zum Beispiel, welche Funktionen wann live gehen sollen.
4) Erfolg und Nutzen messen
- Metriken festlegen, mit denen sich der tatsächliche Nutzen und die Werterzeugung im Produkt auch reaktiv messen lässt.
5) Product Backlog erstellen und pflegen
- Die Übersicht stetig selbst pflegen bzw. verfeinern oder dafür sorgen, dass es im Sinne des Product Owner von anderen erstellt wird.
6) Sprint-Reviews vorbereiten
- Welche Key-Stakeholder werden eingeladen und was sollen sie zu sehen bekommen? Welches Feedback wird von ihnen benötigt? Wer im Team kann welche Funktionen zeigen?
7) An Retrospektiven aktiv teilnehmen
- Wo stehen wir als Team und mit unseren Werkzeugen und Prozessen, wo können wir uns verbessern? An team-internen Aktivitäten zur kontinuierlichen Verbesserung arbeitet der Product Owner genauo mit wie die anderen Teammitglieder.
Verantwortung der Product Owner Rolle
Damit die Product Owner Rolle im umgekehrten, ergebnisoffenen Dreieck der agilen Welt die Hauptverantwortung für die Ausbalancierung und Priorisierung der Aspekte Inhalt, Kosten und Zeit.
Zusammen mit dem Team der Umsetzer ist ein Product Owner außerdem für die Einhaltung von Anforderungen an die Qualität zuständig. Einige Dreiecksmodelle nennen diese gerne als zusätzlich zu beachtende Dimension.
Das „agile Dreieck“ inklusive der Qualität der Arbeitsergebnisse als zentraler Dimension
Insofern lässt sich tatsächlich sagen: Die Product Owner Rolle umfasst viel davon, was klassische Projektleitung beinhaltet.
Allerdings sind Projektmanager:innen auch für die Entwicklung des Projektteams, die Aufgabenverteilung an Projektmitarbeitende und deren Überwachung verantwortlich. Sie können zudem bereits in der Projektinitiierung, wie etwa während der Projektauswahl oder Machbarkeitsprüfungen, in Erscheinung treten.
Dies ist bei der Product Owner Rolle meist anders:
- Lösungsorientierte Produkt-Perspektive
- Agile Product Owner kümmern sich um eine lösungsorientierte Produkt-Perspektive entlang des gesamten Lebenszyklus ihres Produkts. Sie denken an ihr Produkt und dessen Anwender:innen, inklusive betrieblicher Abläufe nach der Erstentwicklung. Dabei lösen sie sich von der reinen Projektdenke.
- Initialer Backlog
- Eine frühe Aufgabe des Product Owner ist typischerweise das Erstellen eines initialen Backlogs (der Liste aller Anforderungen ans Produkt) zusammen mit den Stakeholdern – und eventuell dem Entwicklerteam oder Vertretern daraus.
- Umsetzung des Produkts im Detail
- Das Unterfangen wurde bereits z.B. durch das Produktmanagement entschieden, das im agilen Kontext meist eine übergeordnete Portfolioperspektive hat. Der Product Owner widmet sich hingegen der Umsetzung eines Produkts im Detail.
- Unterstützung durch agile Coaches
- Teamentwicklung, Konflikte, Prozessgestaltung und Regeln für die Zusammenarbeit sind Sache agiler Coaches (in Scrum: Scrum Master). Sie helfen außerdem Product Ownern bei ihren Aufgaben, so dass diese bei Bedarf immer Unterstützung haben.
- Abstimmung mit dem Entwicklerteam
- Die Aufgabenverteilung macht das selbstorganisierte Entwicklerteam unter sich aus. Auch übernimmt es dabei die Qualitätsverantwortung in den Iterationen weitgehend selbst. Das Team muss sich aber häufig mit dem Product Owner abstimmen, damit es hierbei nicht von Zielen, Anforderungen und Marktrealitäten abschweift.
- Gemeinsame Verantwortung mit dem Entwicklerteam
- Statt Berichtswesen zeigen die Developer anhand von regelmäßigen Demonstrationen ihrer Arbeitsergebnisse (z.B. neuen Funktionen im Produkt), wo sie stehen. Beim Product Review für die Stakeholder, am Ende der Iteration, tun Product Owner und Development dies nochmals gemeinsam für alle Personen außerhalb des agilen Produktteams. Gemeinsam übernehmen sie die Verantwortung für die eigenen Resultate.
Projekt- und Produktlebenszyklus sind nicht das Gleiche: Sie betrachten verschiedene Zeitspannen. Product Owner nehmen im agilen Verständnis eine Produkt-Sichtweise ein (oberer Pfeil in der Grafik)
Die wichtigste Verantwortung für die Product Owner Rolle ist es, verschiedene Faktoren gegeneinander abzuwägen und auszubalancieren:
- Kosten, Profitabilität und Rentabilität der Produktentwicklung gegen Kundenzufriedenheit und Marktfähigkeit
- Die oftmals nicht enden wollenden Wünsche und Anforderungen der Stakeholder gegen die Kapazität und Fähigkeiten des Entwicklerteams
- Produktivität des Teams (Output) gegen Ergebnisqualität und Nutzen (Outcome)
- Proaktive Maßnahmen (Risikoerforschung, Entwicklung neuer Funktionen, Integration) gegen reaktive (Tests, Fehlerbehebung, Qualitätssteuerung, Wartung)
Product Owner müssen permanent verschiedene Faktoren der Produktentwicklung gegeneinander abwägen.
Idealerweise können Product Owner in ihrer Rolle diese oftmals konträren Aspekte gut ausbalancieren. Das ist jedoch keine einfache Aufgabe. Um sie gut wahrzunehmen, sollten Personen in dieser Rolle Kenntnisse und Fähigkeiten erlangen und einsetzen, die auch für Projektmanager und Projektmanagerinnen wichtig sind.
Qualifikation: Was muss ein Product Owner können?
Folgende Qualifikation, Kenntnisse und Fähigkeiten sollte ein Product Owner für seine Aufgaben haben:
- Rentabilitätsberechnungen
- Das Sicherstellen von Nutzen durch die entwickelte Lösung („Benefit Engineering“)
- Methoden der Risikoanalyse
- Anforderungsanalyse und Priorisierungstechniken in Bezug auf das Management des Product Backlog
- Stakeholderanalyse und gutes Gespür im Umgang mit diesen Personen
- Sicheres Auftreten und Verhandlungsgeschick
- Innovationsbewusstsein
- Menschenkenntnis, auch im Umgang mit dem Entwicklerteam
Product Owner müssen also mehr können, als der Scrum Guide zu ihrer Rolle angibt.
Was ist „Product Backlog-Management“?
Hierzu finden sich einige Aussagen im Scrum Guide. Dieser sagt Folgendes:
„Das Product Backlog-Management umfasst:
- Die Product Backlog-Einträge klar zu formulieren
- Die Einträge im Product Backlog so zu sortieren, dass Ziele und Missionen optimal erreicht werden können
- Den Wert der Arbeit zu optimieren, die das Entwicklungsteam erledigt
- Sicherzustellen, dass das Product Backlog sichtbar, transparent und für alle klar ist sowie zeigt, woran das Scrum-Team als nächstes arbeiten wird
- Sicherzustellen, dass das Entwicklungsteam die Product Backlog-Einträge im erforderlichen Maße versteht.“
Natürlich reicht auch diese Liste im Scrum Guide allein für die Praxis nicht aus. Dazu ist sie auch keineswegs gedacht. Ein guter Product Owner ist jemand, der es schafft, Requirements Engineering im agilen Kontext zu betreiben.
Zur Verfeinerung des Product Backlogs gehören:
- Entscheidungen zu Backlog-Inhalten
- Was soll im Backlog stehen und was nicht? „Nein“ sagen zu können gegenüber Stakeholdern zu Anfragen, die zum gegenwärtigen Zeitpunkt unpassend oder unrealistisch sind. Ein Unternehmen muss Entscheidungen des Product Owner respektieren, auch wenn es manchmal schwerfällt. Dazu gehört zudem: Neue Einträge hinzufügen, sobald es nötig ist und überflüssig gewordene streichen.
- Entscheidungen zur Art der Einträge
- Funktionsbeschreibungen, Spezifikationen, Bugfixes, nichtfunktionale Anforderungen etwa an Sicherheit, Skalierbarkeit, Wartbarkeit? Oder die ergebnisorientierte Lösungsbeschreibung aus Kundensicht (User Stories) in einem kurzen Satz? Sinnvoll ist die Mischung, da keiner dieser Eintragstypen alle Anforderungen an ein Produkt voll erfüllt.
- Entscheidungen über Anforderungen und Zeitpunkt
- Welche Anforderungen sind für welche Iteration und für welches Release vorgesehen? Konkret ist dies die Sache des gesamten Teams in der Iterationsplanung. Auch die meisten Stakeholder wollen hier gerne mitreden. Eine User Story Map kann hilfreich sein.
- Aufwandsschätzungen
- Das Einholen von groben, relativen Aufwandsschätzungen mit Story Points oder ähnlichem durch das Team. Denn auf Product Backlog-Ebene sind Anforderungen vor allem aus Anwendersicht formuliert. Das Herunterbrechen in Aufgaben erfolgt erst in der Iterationsplanung. Die Aufgaben kommen dann ins Iterations-Backlog.
- Entscheidungen über die Priorität der Einträge
- Im Normalfall ist dies einfach eine lineare Liste im Product Backlog. Das heißt, die Priorität ergibt sich etwa aus der Reihenfolge: Dinge, die weit oben stehen, sind früher umzusetzen als Einträge weiter unten.
Unser Tipp: Formulieren und schätzen Sie nur die obersten Einträge im Backlog besonders gut. Nach unten hin ist dies weniger wichtig, denn diese Einträge könnten sich noch ändern oder ganz herausfallen.
Dieses Vorgehen nach dem „Just-in-Time“-Prinzip hilft Ihnen, Verschwendung durch Aufwand für nicht zeitnah anstehende Anforderungen zu vermeiden. Es folgt den DEEP-Kriterien. Auf diese Weise stellen Sie sicher, dass Ihr Arbeiten mit Product Backlogs agilen Denkweisen folgt und nicht etwa eine Wasserfallplanung mit neuem Namen ist.
Unser Tipp: Wenn Ihnen eine flache, lineare Backlog-Priorisierung nicht ausreicht, können Sie sich mit User Story Mapping als erweiterte Technik zum mehrdimensionalen Backlog-Management auseinandersetzen.
Metriken zur Messung von Produktnutzen
Was sind Metriken zum Messen von Produktnutzen? Diese Frage ist in dieser oder ähnlicher Form beliebt in Product Owner-Zertifizierungsprüfungen wie etwa der Scrum.org. Sie ist zunächst schwer verständlich: Wie messen wir als Team den Wert unseres Produkts? Rein anhand unserer Produktivität sicherlich nicht – diese kann hoch sein, aber wenn die Ergebnisse in die falsche Richtung gehen, bringt uns das kaum etwas.
Tatsächlich gibt das „Evidence-based Management“ einige Metriken vor, die noch teilweise unbekannt sind. Für Product Owner können sie jedoch sehr hilfreich sein.
Das Evidence-based Management kennt vier Hauptkategorien, in die einzelne Metriken fallen:
- Current Value: Er misst, wie das Produkt am Markt angenommen und genutzt wird. Aber es beachtet auch, wie gut die Stimmung im Team derer ist, die es entwickeln. Wie zufrieden sind mögliche Investoren?
Beispielmetriken: Die in diese Kategorie fallen, sind etwa: Kundenzufriedenheitsindizes (bspw. aus Umfragen und Produktfeedback generiert), Messungen der Nutzung einzelner Funktionen im Vergleich zur Kundenzufriedenheit mit diesen. - Time-to-Market: Er misst, wie lange es dauert vom Zeitpunkt, wenn eine neue Anforderung zum ersten Mal formuliert wird, bis der Urheber die Lösung in der Hand hält. Wie schnell lernen wir aus neuen Informationen und verwerten sie?
Beispielmetriken: Release-Häufigkeit, Integrationshäufigkeit, Durchlaufzeit von Backlog-Einträgen, Vorlaufzeit. - Ability to Innovate: Dies ermittelt, wie innovativ die Lösungsfindung ist. Wie neuartig sind die Funktionen und das Produkt generell? Diese Frage sollte auch bei der Weiterentwicklung an gewachsenen Systemen in Großkonzernen gestellt werden.
Beispielmetriken: Nutzung einzelner Funktionen im Vergleich zu anderen, Aufwand oder Kosten für Neuentwicklung (in Prozent) gegenüber reaktiven Tätigkeiten wie Wartung, Messung der Zeit, die das Team tatsächlich am Produkt beschäftigt ist (im Vergleich zu anderen Aufgaben).
- Unrealized Value: Hier geht es darum, welches Potenzial momentan noch nicht ausgeschöpft ist. Wie sinnvoll wäre es, sich damit einmal näher zu beschäftigen?
Beispielmetriken: Marktanteil, Erwartungen der Anwender im Vergleich zu dem, was sie bekommen.
Unser Tipp: Richtig wirkungsvoll sind solche Metriken, wenn Sie diese über längere Zeit hinweg erfassen. Dann können Sie Entwicklungen und Trends recht gut erkennen.
Regelmäßige Auswertung von Metriken, die in der Produktentwicklung relevant sind (Beispiel)
Lesetipp: 3 Jira Tipps für Product Owner, die Sie kennen sollten
Herausforderungen für Product Owner
Bislang haben Sie die Rolle des Product Owner und einige wichtige Werkzeuge und Aufgaben im Detail kennengelernt. Jetzt erfahren Sie, welchen Herausforderungen Product Owner in ihrem Alltag häufig begegnen.
Umfragen durch agile Coaches unter Product Ownern und Developern haben ergeben, dass das vor allem die folgenden Herausforderungen sind:
- Zeitmangel des Product Owner
- Mögliche Probleme: Die Rolle darf nicht in Vollzeit ausgefüllt werden, sondern muss noch neben Linienarbeiten stattfinden. Es sind zu viele Produkte und Teams gleichzeitig zu betreuen. Die Balance zwischen Zeit für Stakeholder und für die Teams ist schwer.
Mögliche Lösung: Ursachenanalyse: Was ist wirklich der Grund für die Zeitprobleme? Was lässt sich ändern? Gibt es Zeitmanagement-Methoden, die helfen könnten? Vielleicht hilft eine Repriorisierung von Projekten und Anforderungen? - Mangelndes Wissen über Aufgaben
- Mögliche Probleme: Der Product Owner weiß zu wenig über die eigene Rolle und agile Entwicklung. Die Rolle wird oft einfach vergeben ohne weitere Erklärung oder Training.
Mögliche Lösung: Weiterbildung, Literatur wie etwa das sehr zu empfehlende Buch „Der professionelle Product Owner“ von Don McGreal und Ralph Jocham. - Mangelndes Wissen zu Tools
- Mögliche Probleme: Der Product Owner kennt nötige / wichtige Dokumente und Metriken für seine Arbeit nicht.
Mögliche Lösung: Auseinandersetzung mit Tools zur Erstellung von Produktvisionen, Impact-, Story- und Roadmaps, Release-Planungsstrategien, Evidence-based Management, Stakeholderanalyse-Werkzeugen. - Mangelnde Entscheidungsgewalt
- Mögliche Probleme: Der Product Owner ist nicht autorisiert zu entscheiden. Eskalationspfade sind zu kompliziert und langwierig.
Mögliche Lösung: Eskalation und Diskussion solcher Probleme auf Metaebene mit dem Management - Probleme mit Stakeholdern
- Mögliche Probleme: Mangelnde Beteiligung und Interesse durch die Stakeholder, Konflikte unter Stakeholdern bzgl. Festsetzung von Prioritäten, zu viele Stakeholder.
Mögliche Lösung: Stakeholderanalyse, Moderationstechniken erlernen und anwenden, Anforderungsanalyse zusammen mit Stakeholdern, etwa m. H. eines Product Vision Canvas, Einbinden agiler Coaches. - Probleme in der Aufbauorganisation
- Mögliche Probleme: Hohe Organisationskomplexität und Silo-Symptome
Mögliche Lösung: Verkürzen der Feedback-Loops mithilfe agiler Coaches - Hohe Projektkomplexität
- Mögliche Probleme: Projekte mit vielen verschiedenen Firmen als Beteiligte. Der Product Owner und die Developer gehören unterschiedlichen Firmen an.
Mögliche Lösung: Dies muss nicht automatisch ein Problem sein, es ist aber ein Thema, mit dem bewusst umgegangen werden sollte: Vertragsgestaltung und Teamvereinbarungen helfen. - Hochregulierte Umgebungen
- Mögliche Probleme: Das Umfeld / die Branche erschwert leichtgewichtige Arbeitsweisen durch Prozessüberbau.
Mögliche Lösung: Situative Intelligenz und Konzentration auf eine gute Fehlerkultur und möglichst schnelles Lernen angesichts der äußeren Umstände.
Product Owner können und müssen all diese Probleme nicht allein lösen. Hier sind oft das Management und die Beteiligung aller Betroffenen sowie zusätzlich gutes Coaching gefragt.
Unser Tipp: Wenn in Ihrem Unternehmen einige der oben beschriebenen Probleme auftreten, lohnt es sich sicherlich, diese möglichst frühzeitig an die zuständige Stelle zu adressieren.
Zusammenfassung: Product Owner
In diesem Artikel haben Sie unter anderem erfahren, welche Aufgaben und Verantwortungen ein Product Owner hat, welche Herausforderungen von ihm zu meistern sind, welche Metriken zur Messung von Produktnutzen es gibt und welche Inhalte das Product Backlog-Management umfasst.
Zusammenfassend lässt sich sagen: Gute Product Owner können ganz wesentlich zum Erfolg eines Unternehmens am Markt beitragen. Sie sind somit in einer sehr spannenden und einflussreichen Position voller Möglichkeiten. Aber die Rolle muss sich gegebenenfalls auch mit schwierigen Herausforderungen auseinandersetzen.
Daher sollten Sie, wenn Sie sich in der Rolle des Product Owner befinden oder diese anstreben, auf permanente Fortbildung einstellen: methodisch, toolseitig und besonders auch im zwischenmenschlichen Umgang.
Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).
Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für ein höheres Reifengrad-Level Ihres Projektmanagements!
Ist Ihre Neugier geweckt? Dann probieren sie agile Methoden mit Ihren Team und in Ihrem Projekt aus! Und wenn Sie Ihr Wissen ausbauen wollen, dann ziehen Sie doch eine Weiterbildung in Betracht – etwa zum Professional Scrum Master (PSM I) oder zum PMI Agile Certified Practitioner (via PMI-ACP Training bei TPG).
Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.
Über die Autorin:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM
Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.
