Product Owner: PO spricht mit Team

Product Owner in Scrum: Rolle, Verantwortlichkeiten und Aufgaben

Der Product Owner ist eine der drei Scrum-Rollen. Als „Produktinhaber“ entwickelt er eine Produktvision, die übergeordneten Ziele und überführt die Probleme, Anforderungen und Ziele aller Stakeholder*innen in Aufgaben für das Scrum-Team. Doch was bedeutet das genau? Was sind die weiteren Aufgaben der Rolle? Und wie wird man Product Owner? Antworten liefert unser Artikel.

E-Book
Product Owner in Scrum: Rolle, Verantwortlichkeiten und Aufgaben
Später lesen? Den vollständigen Leitfaden als E-Book herunterladen.
Jetzt herunterladen

Was ist ein Product Owner?

Der Product Owner (PO) ist eine der drei vom Scrum Guide definierten Rollen im Scrum-Team. Er entwickelt eine Produktvision und ist Interessensvertreter der Kund*innen im Team. Der “Produktinhaber” ist ergebnisverantwortlich für die Maximierung des Produktwerts. Seine drei wichtigsten Aufgaben sind:

  • Management des Product Backlogs: Der PO sammelt die Anforderungen aller Stakeholder*innen an das Produkt, verwandelt sie in Aufgaben und priorisiert die Reihenfolge der Bearbeitung.
  • Stakeholder-Management: Er ist im Austausch mit allen Stakeholder*innen des Produkts (z. B. Kund*innen oder Unternehmensvertreter*innen), um alle Interessen und Bedürfnisse mit einzubeziehen.
  • Release-Management: Der Product Owner trifft die Entscheidung darüber, wann die entwickelten Produkt-Bestandteile (Inkremente) veröffentlicht werden.

Beim Product Owner handelt es sich nicht um eine Position, sondern um eine Rolle, die mit bestimmten Verantwortlichkeiten und Aufgaben betraut ist. Ausgefüllt wird die Rolle durch eine Person, nicht durch ein Gremium oder Komitee.

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

Scrum Guide

Product Owner als Rolle im Scrum-Team 

Das Scrum-Team ist eine „geschlossene Einheit von Fachleuten“ (Scrum Guide). Innerhalb des Scrum-Frameworks arbeitet es selbstorganisiert und verteilt die Verantwortung auf die drei Rollen Scrum Master, Entwickler*innen und Product Owner. Es existiert keine Hierarchie zwischen den Rollen. Alle Teammitglieder arbeiten auf Augenhöhe an einem gemeinsamen Ziel, nur mit unterschiedlichen Verantwortlichkeiten und Aufgaben.

Scrum-Rollen: Die verteilte Führung im Team
Die verteilte Verantwortung der Scrum-Rollen
Die verteilte Verantwortung der Scrum-Rollen

Das crossfunktionale Team verfügt idealerweise über alle fachlichen Kompetenzen und Fähigkeiten, die für die Entwicklung der jeweiligen Lösung notwendig sind und kann deswegen weitgehend eigenständig agieren.

Der Product Owner sorgt dafür, dass wir die richtigen Dinge tun. Das Team sorgt dafür, dass es richtig gemacht wird. Der Scrum Master sorgt dafür, dass es die richtigen Personen tun.

Felix Lagemann
Agile Coach von Me & Company

Product Owner: Rolle und Verantwortlichkeiten

Im Scrum-Team ist der Product Owner Vertreter der Kund*innen und Schnittstelle zwischen Team und allen internen sowie externen Stakeholder*innen. Sein oberstes Ziel ist, mit dem zu entwickelnden Produkt einen Mehrwert für Kund*innen zu schaffen. Hierbei sucht der Product Owner immer einen Ausgleich zwischen Kundenbedürfnissen und den Geschäftsinteressen des Unternehmens: Neben seinem breiten Wissen über die Zielgruppe und die Marktsituation bezieht er die strategischen Zielsetzungen und den Nutzen für seine Organisation in alle Überlegungen ein.

Seine wichtigsten Aktivitäten sind dabei:

  • Langfristiges Ziel definieren: Entwicklung einer Produktvision
  • Interessen sichtbar machen: Informationen von Kund*innen und allen anderen Stakeholder*innen sammeln und strukturieren (z. B. durch Interviews)
  • Produktelemente (Inkremente) ableiten: User oder Job Stories schreiben und als Einträge im Product Backlog einbringen, Verfeinern der Einträge mit dem Team (z. B. im Backlog Refinement) und Formulierung von Akzeptanzkriterien für die einzelnen Einträge
  • Qualitätsstandards definieren: Anforderungen formulieren, Definition of Done und Definition of Ready mit dem Team erarbeiten
  • Prioritäten festlegen: Priorisierung der Backlog-Einträge, Festlegung der Reihenfolge, in der die Einträge bearbeitet werden (im Dialog mit dem Team)
  • Releases managen: Entscheidung über die Veröffentlichung von Produktbestandteilen

Im Vergleich zu Projektleiter*innen oder klassischen Führungskräften nehmen Product Owner eine komplett neue Rolle ein: Sie sind nicht der Vorgesetzte, der hierarchische Verantwortung für das Team und die Arbeitsergebnisse übernimmt. Ihre Verantwortung liegt auf dem Produkt und dessen Wertsteigerung. Die ganzheitliche Verantwortung liegt im Team.

Als Product Owner bin ich nicht der Chef. Ich bin ein normales Teammitglied, nur mit einer anderen Perspektive bzw. einer anderen Rolle.

Andreas Schneider
Product Owner, Zukunftswerkstatt DEVK Versicherungen

Kunden kennen

Kundenzentrierung ist einer der wichtigsten agilen Werte und spielt in der Produktentwicklung mit Scrum eine zentrale Rolle: Voraussetzung für die Entwicklung eines bedarfsgerechten Produkts ist ein tiefes Wissen über die Kund*innen und ihre Bedürfnisse. Der Product Owner setzt sich deswegen permanent mit der Zielgruppe und den Marktanforderungen auseinander.

In vielen Scrum-Teams unterstützen UX-Expert*innen den Product Owner hierbei. Sie recherchieren die notwendigen (Kunden-)Informationen und Markterkenntnisse, aus denen der PO die Bedürfnisse und Interessen der Kunden ergründet und im Product Backlog verarbeitet.

Managen Sie Ihre Projekte mit Scrum

Lernen Sie in unseren “Agile Atoms”, wie Sie das Scrum-Framework auch in Ihrem Unternehmen implementieren. Passen Sie unser modulares Trainingsprogramm individuell auf Ihre Bedürfnisse an.

Zu den Agile Atoms
Scrum-Rollen: Team bespricht Aufgaben

Wert für Unternehmen stiften

Darüber hinaus entwickelt der PO bei der Gestaltung des Produkts, Services oder der Lösung des Teams eine Balance zwischen den Interessen der Kund*innen, Nutzer*innen, des Unternehmens sowie der übrigen Stakeholder*innen. Somit hat der Product Owner immer die Unternehmensstrategie im Fokus. Von seiner Haltung sollte der PO deswegen auch immer selbst ein Unternehmer sein und sich folgende Fragen stellen: Wie zahlt unser Produkt auf die übergeordneten Ziele ein? Wie profitiert unser Unternehmen von dem Produkt?

Ein Hilfsmittel, die Unternehmensstrategie in den Teamalltag zu integrieren, ist das Lean Strategy Board.  Das Canvas-Tool visualisiert die zentralen Elemente der Strategie, aktuelle Herausforderungen und die strategischen Zielbilder. Hiermit behalten agile Teams die Strategie immer im Blick. Durch die integrierten Objective & Key Results (OKR) und Initiativen können Teams das Board zudem nutzen, um die Strategie ins operative Geschäft zu übersetzen und ihren Anteil daran zu messen.

Lean Strategy Board: Methode für agile Führungssysteme
Lean Strategy Board: Methode für agile Führungssysteme
Lean Strategy Board: Methode für agile Führungssysteme

Darüber hinaus ist der PO im ständigen Austausch mit Vertreter*inen aus dem Unternehmen, die wichtigen Input liefern können. Das können Ansprechpartner*innen aus der Unternehmensführung sein. Genauso gefragt sind aber auch beispielsweise Gespräche mit dem Vertrieb oder der Kommunikationsabteilung, die wichtige Hinweise zu Verkaufs- oder Vermarktungsmöglichkeiten geben.

Bei der Pflege des Backlogs und der Priorisierung der Anforderungen muss der Product Owner also immer die Ebenen Kundenbedürfnisse und Unternehmensziele einbeziehen und miteinander abwägen.

Entscheidungsverantwortung für den Produktwert

Als Produktverantwortlicher steht der Product Owner für die Qualität des zu entwickelnden Produkts ein. Das bedeutet auch: Innerhalb der Organisation muss er selbstbestimmt und unabhängig entscheiden können. Natürlich ist er offen für Argumente und Meinungen, letztendlich trägt der PO aber die Entscheidungsverantwortung hinsichtlich der Produktentwicklung.

Damit der Product Owner Erfolg haben kann, muss die gesamte Organisation seine Entscheidungen respektieren. Diese Entscheidungen sind im Inhalt und in der Reihenfolge des Product Backlogs sowie durch das überprüfbare Increment beim Sprint Review sichtbar.

Scrum Guide

Der PO entscheidet, welche Anforderungen in das Product Backlog aufgenommen werden und in welcher Reihenfolge die Backlog-Einträge bearbeitet werden. Auch wenn die Priorisierung in der Praxis oft im Dialog mit dem Team geschieht, liegt die endgültige Entscheidung bei ihm. Möchte jemand die Backlog-Items ändern oder Einfluss auf die Priorisierung nehmen, muss er den PO von der Notwendigkeit und dem Mehrwert überzeugen. In seiner Rolle muss der Product Owner damit auch die Bereitschaft mitbringen, „unbequeme“ Entscheidungen zu treffen, die nicht jedem innerhalb der Organisation gefallen. Sein Fokus liegt dabei immer darauf, Mehrwert für Kund*innen und das Unternehmen zu schaffen.

Infografik Value Card
Die Value Card von Me & Company hilft dabei, Ideen oder Anforderungen nach Kundennutzen und Unternehmenswert zu bewerten.
Die Value Card von Me & Company hilft dabei, Ideen oder Anforderungen nach Kundennutzen und Unternehmenswert zu bewerten.

Aufgaben des Product Owners

Neben dem oben beschriebenen Rollenverständnis und Verantwortlichkeiten hat der Product Owner im Wesentlichen drei Aufgabenbereiche, die er im Scrum-Team wahrnimmt:

  • Backlog-Management: Der PO entwickelt eine Produktvision und erstellt die Backlog-Items. Zudem priorisiert er diese „Unteraufgaben“ und sorgt für einen transparenten, sicheren und verständlichen Product Backlog.
  • Stakeholder-Management: Als Schnittstelle steht er im ständigen Austausch mit Stakeholder*innen des Produkts (Kund*innen, Unternehmensvertreter*innen) und bezieht deren Interessen und Anforderungen ein.
  • Release-Management: Das Team kann während des Scrum-Sprints jederzeit ausliefern. Der PO hat immer im Blick, wann entwickelte Produkt-Inkremente veröffentlicht werden (können).
Agile Leadership Training

Erhalten Sie einen umfassenden Überblick zu den Prinzipien und Werkzeugen agiler Führung. Das Agile Leadership Training vermittelt praxisnah die wichtigsten Aspekte und konkrete Methoden, um als „Servant Leader“ neue Formen der Zusammenarbeit zu unterstützen.

Mehr zum Agile Leadership Training
Team-Mitglied von Me & Company stellt seine Arbeitsergebnisse der Gruppe vor und holt sich Feedback ein

Backlog-Management: mehr als nur Anforderungen sammeln und priorisieren

Der Product Owner ist „Hüter des Backlogs“. Im Product Backlog werden alle User Stories, Anforderungen und Aufgaben gesammelt, die notwendig für die Entwicklung des Produkts sind. Eine der wichtigsten PO-Aufgaben ist das Management und die Pflege des Backlogs. Dies umfasst folgende Tätigkeiten:

  • Entwicklung und Kommunikation einer Produktvision
  • Erstellung und Kommunikation der Product-Backlog-Einträge
  • Festlegung der Reihenfolge der Einträge (Priorisierung)
  • Sicherstellung, dass das Product Backlog transparent, sichtbar und verstanden ist

Teile dieser Aufgaben kann der Product Owner ans Team delegieren (beispielsweise die Erstellung der Backlog-Items). Dabei bleibt er aber weiterhin ergebnisverantwortlich für den Produkt-Mehrwert. Wichtig ist, dass der PO über alle Einträge informiert ist. Wenn andere Teammitglieder Backlog-Items erstellen, sollten sie sich zuvor mit ihm absprechen. In der Praxis erfolgt die Formulierung der Einträge in enger Abstimmung zwischen PO und Entwicklungsteam. Ein geeigneter Rahmen, um darüber zu sprechen und die Items weiter zu verfeinern, ist das Backlog Refinement.

„Ich muss das ‚große Ganze‘ im Blick haben“, erklärt Andreas Schneider, Product Owner in der Zukunftswerkstatt der DEVK Versicherungen. „Ich muss dafür sorgen, dass wir die nächsten Sprints planen können, Stakeholder-Feedback zusammenführen und gewichten, Anforderungen aufnehmen, Stories schreiben und unser Backlog im Blick halten. Dabei versuche ich, das Backlog vorausschauend genug zu planen, sodass wir Vorlaufzeiten berücksichtigen und fixe Termine nicht reißen.“

Product Owner: Team im Meeting
Scrum-Team im Backlog-Refinement
Scrum-Team im Backlog-Refinement

Entwicklung einer Produktvision

Eine der wichtigsten Aufgaben des Product Owners ist die Entwicklung und regelmäßige Aktualisierung einer Produktvision. Dieses Zielbild vom finalen Produkt bildet den Grundstein für die Produktentwicklung, alle Aktivitäten sind darauf ausgerichtet.

Bei der Formulierung der Produktvision stehen drei Überlegungen im Vordergrund:

  • Kund*innen/Zielgruppe: Welche Zielgruppe sprechen wir an? Wer sind unsere Kund*innen?
  • Kundenbedürfnisse: Welche Probleme möchten wir mit unserem Produkt lösen? Welche Vorteile bietet es? Und was ist unser Versprechen an die Nutzer*innen (Value Proposition)?
  • Wert für das Unternehmen: Welche Unternehmensziele unterstützen wir mit der Entwicklung des Produkts? Wie zahlen wir mit dem Produkt auf die Unternehmensstrategie ein?

Die Produktvision ist ein Statement, das den zentralen Wert der Lösung betont. Sie ist eindeutig formuliert, einfach zu verstehen, motivierend und handlungsweisend.

Eine gute Vision fördert die Bindung des Teams an das Produkt und die Identifikation mit den gemeinsamen Zielen. Sie ist damit ausschlaggebend für die erfolgreiche Entwicklung. Sie sollte offen kommuniziert und idealerweise mit den Zielen und Aufgaben verbunden werden: Jedes Teammitglied muss die Vision kennen und auf sie hinarbeiten. Wir empfehlen, die Produktvision jederzeit für das Team sichtbar zu machen. Sie kann quasi als „Überschrift“ über dem Backlog fungieren. Wenn Sie mit einem physischen Board arbeiten, platzieren Sie die Produktvision an prominenter Stelle, damit das Team sie immer vor Augen hat.

Die Vision hilft dem Team,

  • die wichtigsten Merkmale des Produkts zu verstehen,
  • die Aufgaben zu priorisieren sowie einzuschätzen, welche Features umgesetzt werden müssen, um einen Mehrwert für Kunden zu schaffen und
  • zu erkennen, wie die Entwicklung des Produkts die Strategie und Ziele des Unternehmens unterstützt.

Wenn Du ein Schiff bauen willst, dann trommle nicht Männer zusammen, um Holz zu beschaffen, Aufgaben zu vergeben und die Arbeit einzuteilen. Sondern lehre sie die Sehnsucht nach dem weiten, endlosen Meer.

Antoine de Saint-Exupéry
französischer Schriftsteller und Pilot

Erstellung der Product-Backlog-Einträge

Das Product Backlog ist keine fixe Liste, die einmal aufgestellt, priorisiert und dann abgearbeitet wird. Es ist dynamisch und verändert sich über die Zeit: Durch die Erkenntnisse aus den Sprints und (zusätzliche) Anforderungen der Stakeholder*innen erweitert sich das Backlog. Es kommt aber natürlich auch vor, dass Backlog-Items entfernt werden, wenn sie nicht mehr notwendig sind.

Aufgabe des Product Owners ist es, dies immer im Blick zu haben. Er schreibt neue Backlog-Items, aktualisiert bestehende, stellt Akzeptanzkriterien für die Items auf und löscht Einträge, die obsolet geworden sind. All dies geschieht in enger Abstimmung mit dem Entwicklungsteam.

Backlog-Items erklären, was gemacht werden soll und bündeln Anforderungen der Kund*innen und Stakeholder*innen an das Produkt in Epics, User Stories, Tasks oder Bugs:

  • Epic: Ein Epic ist eine größere Anforderung, die nicht in einem Sprint erledigt werden kann. Es wird in der Regel in mehrere User Stories aufgesplittet oder in kleinere Items unterteilt.
  • User Story: Hierbei handelt es sich um eine Anforderung, die innerhalb eines Sprints abgeschlossen werden kann und Mehrwert für den Nutzer liefert. User Stories sind aus der Sicht des Endkunden verfasst.
  • Task: Ein Task ist eine einzelne Aufgabe innerhalb einer User Story, die üblicherweise von einer Person bearbeitet werden kann.
  • Bug: Bugs sind funktionale Fehler, die die Nutzung des Produkts erschweren oder behindern. Der Begriff “Bug” stammt aus der Softwareentwicklung. Aber auch in der Entwicklung physischer Produkte kann es zu Fehlern kommen, die die Nutzerfreundlichkeit erschweren und durch eine neue Lösung oder Fehlerbeseitigung behoben werden müssen.

Backlog Refinement: gemeinsames Verständnis gewinnen

Product Owner und Entwicklungsteam können die Backlog-Items zu jedem Zeitpunkt erstellen. Damit sich das Team synchronisiert und ein gemeinsames Verständnis für das Product Backlog besteht, empfiehlt sich ein regelmäßiges Backlog Refinement. In diesem Meeting bereitet das Team die Backlog-Items für das Sprint Planning vor: Ein gut gepflegtes Backlog macht das Planungstreffen deutlich effizienter.

PO und Entwickler*innen besprechen die hoch priorisierten Einträge und arbeiten diese weiter aus. So werden beispielsweise neue User Stories aufgenommen und formuliert oder bestehende mit neuen Informationen angereichert. Das Team nimmt unter Umständen auch eine Neu-Priorisierung des Backlogs vor, falls sich die Situationen geändert hat oder neue Informationen vorlegen.

Product Owner: Team schätzt Aufwände mit Planning Poker
Viele Teams nutzen das Refinement auch, um Aufwandschätzungen für einzelne Einträge vorzunehmen. Eine Methode dafür: Planning Poker.
Viele Teams nutzen das Refinement auch, um Aufwandschätzungen für einzelne Einträge vorzunehmen. Eine Methode dafür: Planning Poker.

Priorisierung der Backlog-Einträge

Eine der wichtigsten Aufgaben des Product Owners ist die Priorisierung der Backlog-Einträge. Er legt die Reihenfolge der Bearbeitung fest und sortiert das Backlog so, dass die Items mit dem höchsten Kundennutzen oben stehen. Diese Priorisierung ist immens wichtig, um die Arbeit des Scrum-Teams effektiver zu gestalten und Störungen von außen möglichst zu vermeiden.

Die Verantwortung für die Priorisierung liegt beim Product Owner, für eine effektive Zusammenarbeit sollte das Team den Entscheidungen folgen und sie akzeptieren. Aus diesem Grund nimmt der PO die Priorisierung oft gemeinsam bzw. im Austausch mit den Entwickler*innen vor.

Die Priorisierung erfolgt grundlegend auf einer Aufwand- und Nutzenabwägung. Ist der Nutzen (für Kund*innen/das Unternehmen) groß genug, dass sich der Aufwand in der Umsetzung lohnt? Bei der Priorisierung der einzelnen Backlog-Items helfen beispielsweise das Kano-Modell, die MoSCoW-Priorisierung oder auch die Eisenhower-Matrix.

  • Kano-ModellHierbei handelt es sich um eine vom japanischen Wissenschaftler Noriaki Kano entwickelte Befragungsmethode. Das Kano-Modell der Kundenzufriedenheit ermittelt die Wünsche und Erwartungen von Kund*innen an ein Produkt und teilt diese in 5 Merkmale ein (Basis-Merkmale, Leistungs-Merkmale, Begeisterungs-Merkmale, Unerhebliche Merkmale, Rückweisungs-Merkmale).

  • MoSCoW-Priorisierung: Mit dieser Methode lassen sich Anforderungen und Ideen an ein Produkt oder Projekt in vier Kategorien einteilen: M (Must have), S (Should have), C (Could have) und W (Won´t have).
  • Eisenhower-Matrix: Eine schnelle und eindeutige Priorisierung ist mit der Eisenhower-Matrix möglich (auch Eisenhower-Prinzip, benannt nach dem ehemaligen US-amerikanischen Präsidenten Dwight D. Eisenhower). Die Matrix teilt Aufgaben in die zwei grundlegenden Kriterien „Wichtigkeit“(wichtig/unwichtig)  und „Dringlichkeit“ (dringend/nicht-dringend) ein. Die Eisenhower-Matrix ermöglicht vier Kombinationsmöglichkeiten (wichtig/dringend, wichtig/nicht-dringend, unwichtig/dringend, unwichtig/nicht-dringend), nach denen Aufgaben eingeteilt und priorisiert werden können. Die am höchsten priorisierten Aufgaben finden sich in der Matrix demzufolge im Feld „wichtig/dringend“. Für den Scrum-Kontext ist es eventuell sinnvoll, die Matrix anzupassen und in die Kriterien „Nutzen“ (hoch/gering) und „Aufwand“ (hoch/gering) umzubenennen.

Vorbereitung des Sprint Planning

Ein gut gepflegtes und priorisiertes Backlog ist die beste Vorbereitung für das Sprint Planning. In diesem Scrum-Event plant das Scrum-Team den anstehenden Sprint. Der Product Owner bereitet für das Planungstreffen ein Sprintziel vor und definiert die Backlog-Items, die zum Erreichen des Ziels im Sprint umgesetzt werden sollen.

Hierbei ist es wichtig, dass der PO bei der Vorstellung des Sprintziels und der umzusetzenden Items auch immer den Kontext erklärt, wie diese Auswahl auf die langfristige Produktvision einzahlt.

Die Entscheidung über das endgültige Sprintziel treffen die Entwickler*innen und der Product Owner gemeinsam im Sprint Planning. Auch über die Umsetzung der vorgeschlagenen Backlog-Einträge diskutieren sie im Planungstreffen. Der PO teilt diese Aufgaben nicht zu, das Team entscheidet am Ende eigenständig, wie viel Arbeit es im Sprint übernimmt.

Als Agile Coach den Wandel vorantreiben

In unserer berufsbegleitenden Ausbildung erhalten Sie alle Werkzeuge, die es braucht, um die Rolle des Agile Coach einzunehmen. Lernen Sie unsere Trainer und das Programm vorab bei einem unverbindlichen Treffen kennen.

Mehr zur Ausbildung
Agile Coaches sorgen für mehr Kommunikation zwischen Interessensgruppen

Stakeholder-Management: ständiger Austausch mit Interessensgruppen

Neben der Pflege, Kommunikation und Priorisierung des Product Backlogs ist das Stakeholder-Management eine weitere zentrale Aufgabe des Product Owners. In der Regel haben viele Stakeholder*innen Interesse an der Entwicklung des Produkts:

  • Kund*innen
  • Konsument*innen
  • Partner*innen
  • Unternehmensführung
  • Management
  • Fachexpert*innen
  • spezielle Gruppen, wie Bewerber*innen, Presse, Politik oder die allgemeine Öffentlichkeit

Bedürfnisse ermitteln

Der Product Owner steht in ständigem Kontakt mit diesen Gruppen. Er kategorisiert sie nach Relevanz (beispielsweise durch Stakeholder Mapping), baut Beziehungen zu ihnen auf und erarbeitet Bedürfnisse und Anforderungen. Durch die Aufnahme aller relevanten Anforderungen sorgt er für einen sinnvoll strukturiertes und priorisiertes Backlog.

Der Product Owner holt beispielsweise fachliche Anforderungen aus den Fachbereichen des Unternehmens ein. Dies geschieht beispielsweise über Briefings oder Workshops. Zu seinen Aufgaben gehört es hier, die relevanten Aspekten herauszufiltern und ins Backlog zu überführen. Das kann auch bedeuten, dass er widersprüchliche Anforderungen aufdecken und hierfür Lösungen mit den Staheholder*innen entwickelt. Dies kann beispielsweise in Problem-Solution-Workshops passieren.

Wissen über die Kund*innen, Konsument*innen oder die Zielgruppe können der Product Owner und das Scrum-Team mit unterschiedlichen Methoden aufbauen. So können sie die Eigenschaften, Bedürfnisse und Herausforderungen ihrer Zielgruppe beispielsweise mithilfe von Umfragen (z. B. mit dem kostenlosen Online-Tool SurveyMonkey) oder Tiefeninterviews herausarbeiten. Wichtige Daten finden sich in Online-Quellen wie z. B. beim Statistischen Bundesamt oder Statista. Helfen können auch Methoden wie Design Thinking, Empathy Maps oder die Erstellung von Personas.

Erwartungsmanagement

Zu seiner Aufgabe gehört es auch, die festgelegte Priorisierung der Backlog-Einträge gegenüber den Stakeholder*innen zu erklären. Es mag nicht immer allen Kolleg*innen im Unternehmen gefallen, welche Anforderungen wann entwickelt werden. Jede*r Stakeholder*in hält seine Idee in der Regel für die wichtigste und dementsprechend sollte sie auch umgehend umgesetzt werden. Letztendlich entscheidet der PO (gemeinsam mit dem Team) über die Umsetzung – und muss dies auch gegenüber den Anspruchsgruppen kommunizieren.

DEVK-Product-Owner Andreas Schneider erklärt seine Aufgabe so: „Ich versuche uns den Rücken freizuhalten, damit sich das Team auf die Aufgaben des aktuellen Sprints fokussieren kann. Ich sitze in vielen Runden als Teamvertreter. Nicht als ‚Chef‘, der Entscheidungen trifft, sondern um unsere Interessen als Team zu vertreten.“

Product Owner: Gespräch mit Stakeholder
Der Product Owner als Kommunikator: Als Schnittstelle ist der Product Owner im ständigen Austausch mit allen Stakeholdern.
Der Product Owner als Kommunikator: Als Schnittstelle ist der Product Owner im ständigen Austausch mit allen Stakeholdern.

Release-Management: Entscheidung über die Veröffentlichung

Im Sprint-Zyklus existieren keine festen Releasedaten. Der feste Rahmen bedeutet nicht, dass das Team nur am Ende des Sprints ein oder mehrere Produkt-Inkremente ausliefern muss. Idealerweise gibt es mehrere Releases während des Sprints. Der Product Owner muss immer wissen, wann die Releases stattfinden und im Blick haben, wann die entwickelten Lösungen dem Nutzer zur Verfügung stehen.

Die Entwickler*innen entscheiden, wie ein Backlog-Item umgesetzt wird und wann es „fertig“ ist. Hierfür beziehen sie sich in der Regel auf die im Team festgelegte Definition of Done. Diese führt Kriterien auf, wann ein Eintrag als umgesetzt gilt. Da der Product Owner die strategische Zielsetzung des Produkts verantwortet, liegt die letztendliche Entscheidung über die Veröffentlichung bei ihm.

Diese Entscheidungsautorität führt auch dazu, dass der Product Owner der Einzige ist, der einen Sprint vorzeitig stoppen kann. Es kommt vor, dass der PO oder die Entwickler*innen im Sprint feststellen, dass die geplanten Anforderungen (aus unterschiedlichen Gründen) nutzlos geworden oder überholt sind. Dann kann der Product Owner „die Reißleine ziehen“ und den Sprint beenden.

Product Owner: Fähigkeiten und Kompetenzen

Der Product Owner übernimmt im Scrum-Team zahlreiche Verantwortlichkeiten und Aufgaben. Ein Product Owner sollte demnach einige Fähigkeiten und Kompetenzen mitbringen, um die Rolle auszufüllen:

  • Fachliche Expertise und breites Produkt-Wissen: Der Product Owner ist ergebnisverantwortlich für die Produktentwicklung. Er muss also das Produkt in der Tiefe verstehen. Gleichzeitig sollte er den Wert des Produkts für das Unternehmen, Markterfordernisse und Kundenbedürfnisse erkennen und bewerten können. Dies erfordert eine tiefe fachliche Expertise und breites Wissen über Produkt und die Marktanforderungen.
  • Analytisches Denkvermögen: Ein Product Owner trägt viele Informationen zusammen und analysiert, gewichtet sowie priorisiert sie: Anforderungen aus dem Unternehmen an das Produkt, Bedürfnisse und Probleme der Kund*innen, Erkenntnisse über den Wettbewerb. Sein analytisches Denkvermögen hilft ihm dabei, die relevantesten Informationen herauszufiltern und zu effektiven Entscheidungen zu kommen.
  • Kommunikationsfähigkeiten: Der PO kommuniziert mit vielen Gruppen: Er schwört sein Team auf die Produktvision ein und spricht mit Unternehmensvertretern und Kund*innen. Er sollte somit über gute Kommunikationsfähigkeiten verfügen und ein Empathievermögen für verschiedene Anspruchsgruppen besitzen. Eine gute Kommunikation in alle Richtungen ist entscheidend für eine erfolgreiche Produktentwicklung. Dazu gehört, dass er auch „Nein“ zu bestimmten Anforderungen sagen muss (und dank dem Prinzip der Selbstführung agiler Teams auch kann).
  • Methodenwissen: Darüber hinaus sollte der PO ein gutes Verständnis von agilen Methoden mitbringen für die Team-Zusammenarbeit, die Erforschung von Kundenbedürfnissen und zum Aufbau von Produktvision und -strategie (hierbei helfen beispielsweise das Wardley Mapping oder das Value Proposition Canvas). Auch Wissen zu Modellen aus der Verhaltensforschung (z. B. das Fogg Behavior Model oder das Hook-Modell) sind wichtig für die PO-Rolle.
  • Übernahme von Verantwortung: Der Product Owner übernimmt die Verantwortung für den Mehrwert des Produkts. Er engagiert sich für die Vision, das Produkt, Team, Unternehmen und Kund*innen. Als Verantwortlicher übernimmt er Ownership über den Prozess, nimmt an allen Meetings zum Thema teil und arbeitet mit allen Teammitgliedern zusammen.

Wie werde ich Product Owner?

Zunächst einmal können Sie sich auf eine ausgeschriebene Stelle als Product Owner bewerben, wenn Sie die beschriebenen Fähigkeiten mitbringen und die Anforderungen des Unternehmens erfüllen. Oft werden PO-Stellen in Unternehmen auch durch geeignete Mitarbeitende besetzt.

Natürlich spielt „Learning on the Job“ auch beim Product Owner eine wichtige Rolle. Insofern ist ein Quereinstieg in die Rolle möglich. Viele Unternehmen verlangen allerdings eine offizielle Schulung zum Product Owner, die über eine Zertifizierung nachgewiesen werden kann.

Die bekanntesten sind die zwei Zertifikate von Scrum Alliance und Scrum.org:

  • Certified Scrum Product Owner® (Scrum Alliance): Erforderlich für die Erlangung des Zertifikats sind eine Schulung durch einen Certified Scrum Trainer oder einen Certified Enterprise Coach mit anschließendem Test.
  • Professional Scrum Product Owner™ (Scrum.org): Hier muss nur der Test bestanden werden. Wie Sie sich das Wissen hierfür aneignen, ist Ihnen überlassen.

Beide Organisationen bieten zudem weitere Fortbildungen für zertifizierte PO an: Bei der Scrum Alliance können Sie sich zum „Advanced Certified Scrum Product Owner“ zertifizieren lassen. Scrum.org bietet zusätzlich die Zertifizierung Professional Scrum Product Owner II und III an.

Mit diesen Schulungen lernen Sie die scrum-bezogenen Aufgaben eines Product Owners kennen. Damit Sie eine gute Vision entwickeln, die Bedürfnisse von Stakeholder*innen ermitteln und lernen, ein gutes Produkt zu entwickeln, braucht es jedoch mehr als eine zweitägige Schulung.

Konferenzen und Ausbildungen

Viele Product Owner bilden sich auf Konferenzen für ihre Aufgaben fort oder aus. Es gibt einige gute und anerkannte Formate, bei denen sich Product Owner das notwendige Wissen verschaffen können. Hier eine kleine Auswahl aus unserer Sicht empfehlenswerter Veranstaltungen:

  • From Business to Buttons: Die Konferenz für User Experience and Service Design findet jährlich in Stockholm (Schweden) statt.
  • UXLx User Experience Lisbon: Auf Europas größter UX-Konferenz im portugiesischen Lissabon treffen sich jährlich Product Owner, UX-Expert*innen oder Entwickler*innen.
  • Mind the Product: Unter dem Banner “Mind the Product” finden jährlich mehrere Konferenzen zum Thema Produktmanagement statt. Die drei wichtigsten sind in San Francisco (USA), London (England) und eine regionale Konferenz in Hamburg (Deutschland).

Neben den oben genannten Zertifizierungen gibt es einige hilfreiche Ausbildungen, die Product Owner auf ihre Aufgaben vorbereiten:

Zusammenfassung

Als eine der drei Scrum-Rollen entwickelt der Product Owner eine Vision für das zu entwickelnde Produkt. Zudem übernimmt er Verantwortung für die stetige Steigerung des Produktnutzens. Seine Hauptaufgaben sind das Management des Product Backlogs, der stetige Austausch mit Stakeholder*innen und das Release-Management. Der Product Owner ist nicht der Vorgesetzte des Scrum-Teams, sondern ein Teammitglied mit anderen Aufgaben und Verantwortlichkeiten.

Ein guter Product Owner ist Fachexpert*in in seinem Bereich. Er besitzt analytisches Denkvermögen und verfügt über gute Kommunikationsfähigkeiten. Zudem ist er bereit, Verantwortung im Team und Unternehmen zu übernehmen.

Managen Sie Ihre Projekte mit Scrum

Lernen Sie in unseren “Agile Atoms”, wie Sie das Scrum-Framework auch in Ihrem Unternehmen implementieren. Passen Sie unser modulares Trainingsprogramm individuell auf Ihre Bedürfnisse an.

Zu den Agile Atoms
Vanessa Bern von Me & Company visualisiert Arbeit mit Post Its
NACH OBEN