Was ist ein Product Owner und was macht er in agilen Teams?

Was beinhaltet die Verantwortung des Product Owners genau?

Damit hat der Product Owner 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 könnte man tatsächlich sagen: Product Owner tun viel davon, was klassische Projektmanager übernehmen.

Allerdings sind Projektmanager auch für die Entwicklung des Projektteams, die Aufgabenverteilung an Projektmitarbeiter 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 beim Product Owner 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, inklusive betrieblicher Abläufe nach der Erstentwicklung. Dabei lösen sie sich von der reinen Projektdenke.

Initialer Backlog

Eine frühe Aufgabe des Product Owners 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 Entwickler 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 Entwicklerteam dies nochmal 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)

Was muss ein guter Product Owner können?

Die wichtigste Verantwortung für Product Owner 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 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 wichtig sind.

Dazu gehören unter anderem folgende Kenntnisse und Fähigkeiten:

• 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 sind die Aufgaben eines Product Owners?

Wichtige Aufgaben des Product Owners im Detail sind etwa:

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 Entwickler 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.

Alle 14 Tage – der TPG Projektmanagement Podcast für Unternehmen. Schicken Sie uns doch gerne Ihre Themenwünsche und Feedbacks an podcast@theprojectgroup.com.

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 Owners 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.

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 können gegenüber Stakeholdern zu Anfragen, die zum gegenwärtigen Zeitpunkt unpassend oder unrealistisch sind. Ein Unternehmen muss Entscheidungen des Product Owners 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 Backlogmanagement auseinandersetzen.

Was sind Metriken zur Messung 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 Potential 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)

Welche Herausforderungen müssen Product Owner meistern?

Bislang haben Sie die Rolle des Product Owners und einige wichtige Werkzeuge und Aufgaben im Detail kennengelernt. Jetzt erfahren Sie, welchen Herausforderungen diese in ihrem Alltag häufig begegnen.

Umfragen durch agile Coaches unter Product Ownern und Entwicklern haben ergeben, dass das vor allem die folgenden Herausforderungen sind:

Zeitmangel des Product Owners

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 Entwickler 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

In diesem Artikel haben Sie unter anderem erfahren, welche

• Aufgaben ein Product Owner hat,
• Herausforderungen von ihm zu meistern sind,
• Metriken zur Messung von Produktnutzen es gibt und
• 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 Owners befinden oder diese anstreben, auf permanente Fortbildung einstellen: methodisch, toolseitig und besonders auch im zwischenmenschlichen Umgang.

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).

Sind agile Methoden für Ihr Arbeitsumfeld geeignet? Scheiben Sie gerne einen Kommentar.

---

Über die Autorin: Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum. 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. Als ursprünglich ausgebildete Expertin für Sprachen und Medien verfügt sie mittlerweile neben fünf Jahren Trainingserfahrung auch über 11 Jahre Erfahrung im Projektumfeld. Sie ist seit 12 Jahren im PMI Southern Germany Chapter e.V. aktiv in den Bereichen Kommunikation, Social Media und Organisation englisch-sprachiger Treffen.

Mehr über Antje Lehmann-Benz auf Linkedin oder Xing.