Product Owner

Die Aufgaben des Product Owners

Nach dem aktuellen Scrum Guide 2020 hat der Product Owner – oftmals auch einfach als PO abgekürzt – folgende vier Aufgaben:

1. die Entwicklung und explizite Kommunikation des Product Goals (Produktziels),
2. die Erstellung und klare Kommunikation der Product Backlog Items,
3. das Sortieren der Product Backlog Items und
4. das Sicherstellen, dass das Product Backlog transparent, sichtbar und verständlich ist.

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

• 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 Produkt 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 PO 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 Konflikte zu vermeiden, sollte es keine Doppelfunktion als Scrum Master oder Entwickler geben.

Immer wieder wird behauptet, dass der PO 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 er 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 PO:

• 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 die Position angesiedelt sein sollte. Die meisten Organisationen verordnen die Rollen (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 PO 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.

Impulse zum Diskutieren:

[1] Nicht nur der PO 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?

[2] Ist in einem guten PO ein vollständiger Produktmanager enthalten?

Hinweise:

Haben Sie Lust auf einen neuen Lieblings-Newsletter?

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

[1] Hier finden Sie weitere Informationen zur Scrum Alliance.
[2] Hier finden Sie weitere Informationen zu Scrum.org.

Das LeSS Huge Framework kennt übrigens Product Owner Teams.

Hier finden Sie einen Podcast zum Thema: Was bedeutet der neue Scrum Guide für Product Owner?

Hier finden Sie Anti-Tipps für Product Owner als Download.

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

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.