Product Owner

Was ist ein Product Owner, welche Aufgaben hat er und wo ist er in der Organisation angesiedelt?

Verantwortlich für Product Backlog Management und Product Goal

Scrum definiert drei Accountabilitys bzw. Verantwortlichkeiten:

  • den Scrum Master,
  • die Developer bzw. Entwickler und
  • den Product Owner.

Der Product Owner – ins Deutsche übersetzt: der Produkteigentümer – ist für die Wertsteigerung des Produkts im Entwicklungsprozess zuständig und verantwortet das Product Backlog und Product Goal.

In der Praxis ist er häufig derjenige, der die fachliche Sicht vertritt und als Ansprechpartner für die Developer agiert. Er formuliert u.a. Anforderungen an die gewünschte Lösung und beurteilt Entwicklungsfortschritte anhand von Funktionalität, Usability und Qualität.

Product Owner - eine Art Superheld?

Die Aufgaben des Product Owners

Nach dem aktuellen Scrum Guide 2020 hat der Product Owner folgende vier Aufgaben:

  • die Entwicklung und explizite Kommunikation des Product Goals (Produkt-Ziels),
  • die Erstellung und klare Kommunikation der Product Backlog Items,
  • das Sortieren der Product Backlog Items und
  • das Sicherstellen, dass das Product Backlog transparent, sichtbar und verständlich ist.

Ergänzend führt der Scrum Guide aus, dass der Product Owner

  • die genannten Aufgaben delegieren kann, er aber die Verantwortung trägt.
  • dafür verantwortlich ist, den Wert eines Produkts durch die Arbeit des Scrum Teams zu maximieren.
  • die Bedürfnisse der Stakeholder repräsentiert, Änderungen am Product Backlog jedoch nur erfolgen, sofern er als verantwortliche Person davon überzeugt wird.
  • derjenige ist, mit dem in einem Sprint der Scope geklärt und ggfs. in einem laufenden Sprint neu verhandelt werden kann, sobald neue Erkenntnisse vorliegen.
  • die Autorität besitzt, einen Sprint abzubrechen.
  • sicherstellt, das die Teilnehmer am Sprint Planning vorbereitet und in der Lage sind, über die wichtigsten Product Backlog Items auf dem Weg zum Product Goal zu diskutieren.
  • im Sprint Planning vorschlägt, wie das Product im aktuellen Sprint seinen Wert und Nutzen steigern könnte.
  • bei einer Teilnahme am Daily Scrum als Developer und damit als Teil des Scrum Teams teilnimmt.
  • bei Bedarf die Entwickler im Backlog Refinement beim Sizing der Items unterstützt
  • eine Person ist und es sich nicht um eine Gruppe oder ein Komitee handelt.

Damit der Product Owner erfolgreich arbeiten kann, muss – laut Scrum Guide – die gesamte Organisation seine Entscheidungen respektieren, die durch die Inhalte und Reihenfolge der Product Backlog Items, sowie die Inkremente am Ende der Sprints einsehbar sind. 

Weitere Tätigkeiten in der Praxis

Neben den Aufgaben aus dem Scrum Guide gibt es in der Praxis Tätigkeiten, die häufig in das Betätigungsfeld des Product Owners fallen, wie bspw.

  • die regelmäßige Kommunikation mit Stakeholdern, und damit auch die Vorstellung und Vertretung ihrer Bedürfnisse.
  • die Verantwortung für Releases und Releasepläne. Ob die Roadmap des zu erstellenden Produkts in seiner Verantwortung oder in der des Scrum Teams liegt, ist kontextabhängig.
  • die Klärung von Backlog Items im Sprint Review, die erledigt wurden oder noch offen sind (die an sich nicht präsentiert werden sollten).
  • die Vereinbarung des Sprint-Ziels mit den Developern und die Klärung der Umzusetzenden User Storys.

Darüber hinaus ist es oftmals fachlicher Ansprechpartner des Scrum Masters und der Entwickler und sollte regelmäßig und idealerweise auch kurzfristig für Fragen zur Verfügung stehen.

Immer wieder gibt es in der Praxis Diskussionen darüber, ob der Product Owner die Gesamtverantwortung für das Produkt trägt und für den Erfolg des Produkts und in letzter Konsequenz auch für Marketing, Verkauf, Entwicklung, Betrieb und Support verantwortlich ist. Es empfiehlt sich, den konkreten Kontext einer Organisation zu beachten und ein gemeinsames Verständnis zu den Verantwortlichkeiten, Aufgaben und Rollen zu finden, zumal es in vielen Organisationen bereits ein Erfolg wäre, wenn Vertreter der genannten Bereiche an dem Sprint Review teilnehmen. 

Was ist ein Product Owner NICHT?

Es ist wichtig zu verstehen, was ein Product Owner NICHT ist:

  • Er ist nicht der Projektleiter – den gibt es in dieser Form in Scrum nicht.
  • Er ist nicht der Vorgesetzte der Entwickler – durch den selbstbestimmten Ansatz des Scrum Teams, der sich aus den Prinzipien des Agilen Manifests und der Förderung des Selbstmanagement im Scrum Guide ergibt, gibt es eine solche Führungsaufgabe nicht.
  • Er ist nicht der Moderator in diversen Scrum Events wie bspw. im Daily Scrum.

Er kann, muss aber kein Manager in der Linienorganisation sein; wichtig ist die Fähigkeit die Stakeholder fachlich kompetent zu vertreten. Grundsätzlich sollte der Scrum Master bei Bedarf eingreifen und auf die Einhaltung der im Scrum Guide definierten Verantwortlichkeiten achten. Um mögliche Interessenskonflikte zu vermeiden, sollte der Product Owner keine Doppelfunktion als Scrum Master oder Entwickler einnehmen.

Immer wieder wird behauptet, dass der Product Owner als Vertreter der Nutzer für die Formulierung von User Storys verantwortlich ist. Dies ist nicht der Fall. Abgesehen davon, dass es kontextabhängig ist, welche Elemente im Product Backlog verwaltet werden, ist es letztendlich sekundär, wer diese formuliert. Die Verantwortung über das Product Backlog und das Product Goal obliegt dem Product Owner, aber wichtig ist vor allen, dass sich Nutzer und Entwickler verstehen. Dazu muss der Product Owner seinen Beitrag leisten. Wie er dies tut, hängt von der Situation ab. Und wie gut er es tut, lässt sich im Zuge von Retrospektiven thematisieren.

Product Owner Zertifizierung

Es gibt zwei anerkannte Product Owner Zertifikate:

  • Certified Scrum Product Owner (CSPO), angeboten von der Scrum Alliance¹
  • Professional Scrum Product Owner (PSPO), angeboten von Scrum.org²

Genau wie bei der Unterscheidung zwischen dem Certified Scrum Master (CSM) und dem Professional Scrum Master (PSM) findet sich der wesentliche Unterschied zwischen dem CSPO und dem PSPO in der Art der Zertifizierung. Zur Erlangung des CSPO-Zertifikat ist eine Schulung – durchgeführt durch einen Certified Scrum Trainer (CST) oder einem Certified Enterprise Coach (CEC) mit anschließendem Test notwendig. Das PSPO-Zertifikat erfordert keine Schulung, sondern lediglich das Bestehen eines Tests.

Nach dem CSPO bzw. PSPO gibt es weitere Ausbaustufen für zertifizierte Product Owner:

  • Advanced Certified Scrum Product Owner (A-CSPO), angeboten von der Scrum Alliance
  • Professional Scrum Product Owner II + III, angeboten von Scrum.org

Wie alle Zertifikate der Scrum Alliance muss auch das CSPO alle zwei Jahre rezertifiziert werden. Bei Scrum.org gibt es keine solche Forderung.

Sitzt der Product Owner im Fachbereich oder in der IT?

Kommt der Product Owner aus dem Fachbereich oder der IT? In vielen Unternehmen gibt es Überlegungen, wo der Product Owner angesiedelt sein sollte. Die meisten Organisationen verordnen die Rolle (und auch die Accountability) – sofern er nicht vom externen Auftraggeber gestellt wird – im Fachbereich. Je nach Kontext kann die Antwort jedoch variieren: handelt es sich bspw. um einen Konzern oder befindet sich die Organisation in einer agilen Transformation, könnte es auch sein, dass der Product Owner aus der IT stammt, um bspw. den laufenden Betrieb und die Sicherheit einer Lösung zu garantieren. Doch selbst in einer solchen Situation muss der Fachbereich „die Richtung vorgeben“ und der IT-Bereich dafür sorgen, dass alles „Notwendige“ berücksichtigt wird, denn nur so steht der „Kundenfokus“ über dem „Systemfokus“. Im Sinne einer kontinuierlichen Verbesserung kann es zudem sinnvoll sein, solche und ähnliche Fragen in Organisationen immer wieder zu thematisieren und kontinuierlich nach der individuell besten Lösung zu suchen.

Product Owner Checkliste als Download

Jetzt die Product Owner Checkliste kostenlos downloaden.

Mit der Checkliste halten Sie verschiedene Informationen fest, die für die Arbeit des Product Owners wesentlich sind:

  • Wie lautet das Produkt-Ziel?
  • Wer sind die wichtigsten Stakeholder, welche Ziele verfolgen Sie und wie werden diese im Laufe der Entwicklung überprüft?
  • Wie erfolgt die Arbeit mit Backlogs?
  • Wie und durch wen werden Aufwände geschätzt?
  • Wie funktioniert die Zusammenarbeit mit dem Scrum Master und den Entwicklern?

Checkliste als Arbeitsmittel für Product Owner.

Ein Impuls zum Diskutieren:

Nicht nur der Product Owner sollte mit Stakeholdern sprechen, auch Teammitglieder sind aufgefordert, sich bspw. mit Anwendern auszutauschen. Wie funktioniert dies wohl aus Sicht der Stakeholder, wenn diese zahlreiche Ansprechpartner haben?

Hinweise:

[1] Weitere Informationen zur Scrum Alliance finden Sie hier.
[2] Weitere Informationen zu Scrum.org finden Sie hier.

Hier finden Sie einen Podcast zum Thema: Was bedeutet der neue Scrum Guide für Product Owner? Ein Gespräch Tim Klein, Dominique Winter und Alexander Hardt.

Hier finden Sie ein Scrum Whitepaper als Download.

Und hier finden Sie ergänzende Informationen aus unserem Blog:

t2informatik Blog: Das Product Owner Team

Das Product Owner Team

t2informatik Blog: Boost your Backlog

Boost your Backlog

t2informatik Blog: Agilität? Haben wir probiert! Funktioniert nicht!

Agilität? Haben wir probiert! Funktioniert nicht!