Verantwortung als Product Owner

Verantwortung als Product Owner

Eine zentrale Rolle in jedem agilen Team, ist die des Product Owner. Welche Verantwortung Du als Product Owner übernimmst und welche Fehler Du vermeiden solltest, behandeln wir in diesem Artikel. Dazu gibt es noch viele Tipps aus der Praxis zur Arbeit als Product Owner.

Die Rolle des Product Owners stammt ursprünglich aus dem Scrum Framework. Aber inzwischen arbeiten auch zahlreiche agile Entwicklungsteams außerhalb des Scrum Frameworks mit einem Product Owner, der die entsprechenden Aufgaben wahrnimmt.

Die brennendsten Fragen eines Product Owners

In meinen Trainings bekomme ich häufig Fragen zur Arbeit als Product Owner gestellt. Dabei bekomme ich die folgenden Fragen sehr oft gestellt:

  • Welche Verantwortung habe ich als Product Owner?
  • Wie schreibe ich gute User Stories?
  • Wie pflege ich das Product Backlog?
  • Wie kommuniziere ich mit Stakeholdern effektiv?
  • Welches Tool verwende ich für das Product Backlog?
  • Wie erstelle ich gute Sprint Goals?
  • Wie gelingt mir der Start in der Praxis?
  • Was sind häufige Fehler von neuen Product Ownern?

Verantwortlichkeiten eines Product Owner im Podcast anhören

Welche Verantwortung habe ich als Product Owner?

Um diese Frage zu beantworten schauen wir zunächst im Scrum Guide nach der Definition des Product Owner:

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.

Scrum Guide

Die wichtigste Aufgabe ist die Vertretung der Interessen des Kunden sowie die Zusammenarbeit mit den Stakeholdern. Dazu gehört auch an passender Stelle Nein sagen zu können. Der Product Owner ist das öffentliche Gesicht des Produkts und trägt die Verantwortung für den Erfolg.

Es liegt auch in der Verantwortung des Product Owners, mit jedem Stakeholder in regelmäßigem Kontakt zu stehen. Ebenfalls in der Verantwortung des Product Owner ist die Erstellung und Pflege des Product Backlogs und das Schreiben der User Stories.

Wie schreibe ich gute User Stories?

Als Product Owner formulieren Sie in den User Storys die Wünsche und Anforderungen der Anwender für das Produkt. Gute User Stories beschreiben den Nutzen, den der Benutzer erreichen möchte.

Es muss dabei aber nicht zwangsläufig die Aufgabe des POs sein, User Stories zu schreiben. In einigen Fällen kann dies auch von den Developern übernommen werden.

Beachten bei den User Stories immer die CCC-Regel: Card – Conversation – Confirmation

  • Card: die Karte sollte gerade genug Text enthalten um die Story zu identifizieren
  • Conversation: Die Details der Story werden in Gesprächen zwischen dem Kunden und dem Entwicklungsteam kommuniziert.
  • Confirmation: Die Karten enthalten die Akzeptanzkriterien des Kunden um so zu bestätigen, dass die User Stories korrekt implementiert wurden.

Als Product Owner solltest Du die User Story als Diskussionsmittel mit den Entwicklern und Stakeholdern nutzen.

Wie pflege ich das Product Backlog?

Eine weitere Verantwortung als Product Owner ist die Pflege des Product Backlogs. Das Product Backlog auf den aktuellen Stand zu bringen und zu verfeinern ist ein regelmäßiger Prozess, an dem neben dem PO auch die Developer beteiligt sind. Im Backlog befinden sich alle Ideen und Anforderungen für die weitere Entwicklung Projekts.

In den Refinement-Meetings priorisiert der Product Owner die Anforderungen mit den Developern die den Aufwand der Umsetzung schätzen. Das übergeordnete Ziel ist, dass die Developer die Produkt-Vision und die User Stories verstehen. Dabei können auch Developer User Stories erstellen.

Das Backlog ist ein Tool zu dem auch andere Beteiligte als der PO proaktiv beitragen können. Die Verantwortung des Product Owner liegt aber darin alle Items im Backlog zu verstehen, es zu aktualisieren und vor allem zu priorisieren.

Auf Basis des aktualisierten Backlogs erstellt der PO die Sprint Planung.

Dabei wird die Reihenfolge der Sprints in Abstimmung mit den Stakeholdern festgelegt. Womit wir zu einer der nächsten großen Aufgaben kommen: die Kommunikation mit den Stakeholdern.

Wie kommuniziere ich mit Stakeholdern effektiv?

Stakeholder sind alle Personen, Personengruppen oder Organisationen, die entweder aktiv an einem Projekt beteiligt sind oder durch das Projekt beeinflusst werden. Die Analyse und  Organisation der Stakeholder, sowie die Kommunikation gehört zu den Verantwortungen des Product Owners.

Ein hilfreiches Tool zur Organisation und Analyse ist die sogenannte Stakeholder Map. In dieser werden die Stakeholder untereinander oder auch die Beziehungen zwischen den Stakeholdern und einem Sachverhalt grafisch erfasst und dokumentiert. Auch der Einfluss und die Wichtigkeit des jeweiligen Stakeholders wird dargestellt und ermöglicht Ihnen so die Erstellung des Kommunikationsplans.

Im Kommunikationsplan legt der Product Owner genau fest, auf welchem Wege, wie oft und wann mit dem jeweiligen Stakeholder kommuniziert wird und wer dafür zuständig ist. Siehe dazu auch unseren Artikel zur Stakeholder Map.

Welches Tool verwende ich für das Product Backlog?

Bei der Vielzahl der Aufgaben und Verantwortlichkeiten greifen Product Owner zur Unterstützung auf Online Projektmanagement Tools zurück. Mögliche Tools, die gerade bei der Erstellung und Pflege des Backlogs nützlich sind sind unter anderem Jira oder oder pgforce.

Dabei könnte das Backlog aber auch einfach aus handgeschriebenen PostIts bestehen.

Was bei der Erstellung und Pflege des Backlogs zählt, ist nicht das verwendete Tool sondern die Art und Weise, wie Aufgaben aufgeschrieben und diskutiert werden.

Patric Eid

Statt sich zu viel mit den Tools und der Organisation des Backlogs zu beschäftigen, sollte der Fokus auf der Art und Weise liegen, wie die Aufgaben mit dem Team besprochen werden. Hier zählen vor allem Transparenz und das Einbinden des Teams in den Erstellungsprozess. Und natürlich auch die Kommunikation mit den Stakeholdern.

Wie erstelle ich gute Sprint Goals?

Die Sprint Ziele werden gemeinsam mit dem Product Owner, dem Entwicklungsteam und dem Scrum Master definiert. Dabei bringt meist der PO ein Ziel als Vorschlag in das Team, welches dann diskutiert wird. Ist sich das Team einig wird das Ziel klar formuliert und in den Sprint übernommen.

Bei der Formulierung des Sprint Goals kann sich der PO an folgenden Vorgaben orientieren.

Das Sprint Goal besteht aus 1 bis 2 Sätzen, ist messbar, ist fachlich formuliert und hat als Vorgabe, dass alle externen Abhängigkeiten gelöst sind.

Als praktisch haben sich möglichst einfach formulierte Ziele erwiesen.

Wie gelingt mir der Start in die Praxis?

Für einen guten Start in die Praxis solltest Du als PO klare Prioritäten setzen und Dich fokussieren. Halte das Erstellen von User Stories möglichst einfach und denke nicht zu komplex. In diesem Fall ist es besser zu wenig zu dokumentieren als zu viel. Die Retrospektiven mit dem Team sollten zur Verbesserung der User Stories genutzt werden. 

Höre in diesen Retrospektiven genau hin, beim Feedback zur Qualität der User Stories. Aus diesem Feedback lässt sich eine Definition of Ready ableiten und so als Best Practices formalisieren, so dass ein gewisser Qualitätsstandard gewahrt bleibt. Aber nicht direkt mit einer DoR starten! Die entsteht auch in den nachfolgenden Retrospektiven.

Der Fokus sollte auf dem nächsten Sprint liegen. Was danach kommt, ist erstmal noch nicht wichtig. In der Startphase geht es um das schnelle Lernen und darum, Prozesse und Arbeitsweisen zu verbessern.

Was sind häufige Fehler von neuen Product Ownern?

Einer der häufigsten Fehler in als Product Owner ist eine unklare Priorisierung. Die Pflege und Priorisierung des Produkt Backlogs ist die vorrangige Aufgabe des PO und muss unbedingt konstant und konsequent erfolgen. 

Eine weitere Herausforderung gerade für neue Product Owner ist das Produktverständnis. Ohne dieses ist die Entwicklung einer klaren Vision und die Priorisierung der Items im Backlog kaum möglich. 

Mit der Vielzahl der Verantwortlichkeiten als Product Owner solltest Du auch eine klare Führungspersönlichkeit mitbringen und Vorschläge auch ablehnen können, wenn sie der gesetzten Version und dem Ziel nicht entsprechen.

Welche Fragen hast Du?

Hast Du Fragen zur Arbeit als Product Owner oder Projektleiter:in? Dann kontaktiere mich gerne über LinkedIn. Mein LinkedIn-Profil findest Du hier:

https://www.linkedin.com/in/patric-eid/

Das könnte Dich auch interessieren:

Projektstart Checkliste

Checkliste für einen effektiven und nachhaltigen Projektstart.