Aufgaben und Verantwortlichkeiten eines Scrum Product Owners

Scrum ist ein Framework zur Entwicklung komplexer Produkte, das auf den Grundsätzen der agilen Softwareentwicklung basiert. Es besteht aus den drei Rollen Product Owner, Development Team und Scrum Master, die zusammen das Scrum Team bilden. Darüber hinaus beschreibt Scrum lediglich einige Ereignisse, Artefakte und wenige Regeln. Wie sieht das in der Praxis aus? Für den erfolgreichen Einsatz in der Praxis muss man Scrum mit Leben füllen. Das bedeutet, sich über die Verantwortlichkeiten und Aufgaben der drei Rollen Gedanken zu machen und festzulegen, welche konkreten Techniken, Methoden und Werkzeuge zum Einsatz kommen sollen, beispielsweise im Kontext von Requirements Engineering, Releaseplanung und Qualitätssicherung.

Der Product Owner

Aufgaben und Verantwortlichkeiten der Scrum Product Owner Rolle

Die Rolle des Product Owners ist oft mit einer viel zu hohen Erwartungshaltung verbunden. Der Product Owner muss die unterschiedlichsten Ziele und Anforderungen zahlreicher Stakeholder unter einen Hut bekommen.

Gleichzeitig steht für die gute Ausübung der Rolle häufig zu wenig Zeit zur Verfügung. Um diesem Dilemma zu begegnen, sollte man sich zunächst einmal Klarheit darüber verschaffen, welche Erwartungen die Stakeholder, insbesondere der Kunde und das Management, an den Product Owner stellen. Anschließend arbeitet man heraus, welche Aufgaben und Verantwortlichkeiten mit der Product Owner Rolle verbunden sind. Hierzu möchte ich im Folgenden ein Vorgehen in vier Schritten vorstellen:

Schritt 1: Aufgabenbereiche und Tätigkeiten ermitteln

Der Product Owner maximiert den Wert des Produktes. Er kennt seine Kunden, verwaltet und priorisiert die Anforderungen und steuert dadurch die Entwicklung. Welche Aufgaben leiten sich daraus ab?

In einem Workshop werden zunächst vier grobe Aufgabenbereiche „Kommunikation“, „Requirements Engineering“, „Zusammenarbeit mit dem Team“ und „Messen, Schätzen, Planen, Berichten“ festgelegt und dann mit Hilfe der Brainstorming-Technik konkrete Tätigkeiten gesammelt.

Die ermittelten Tätigkeiten werden dann weiter verfeinert, in dem beschrieben wird, in welchem Kontext sie durchgeführt werden, beispielsweise

  • in welchem Termin oder Gremium?
  • mit welcher Frequenz? (täglich, wöchentlich, quartalsweise, ...)
  • wie viel Zeit wird benötigt?
  • mit welchen beteiligten Personen?

Bei der Diskussion kommt häufig die Frage auf, ob der Product Owner die betreffende Tätigkeit selbst ausführt, oder ob er lediglich das Ergebnis verantwortet. Zur Klarstellung werden die identifizierten Tätigkeiten mit Hilfe der RACI-Technik gekennzeichnet.

Schritt 2: Vollständigkeit und Korrektheit prüfen

Um die Vollständigkeit und Korrektheit der in Schritt 1 ermittelten Aufgaben zu prüfen, wird eine klassische Stakeholder-Analyse durchgeführt und für jeden Stakeholder die Frage gestellt, welche Erwartungen dieser Stakeholder an das Projekt und den Product Owner hat. Darüber hinaus betrachtet man die Artefakte und Werkzeuge, die im Rahmen des Projektes entstehen bzw. zum Einsatz kommen. Dabei wird jeweils verifiziert, welche Aufgaben und Verantwortlichkeiten dem Product Owner bei der Erstellung und Pflege eines Artefaktes zukommen. Dabei sollte man unter anderem an folgende Dinge denken:

  • Product Backlog
  • Epics, User Stories, Anforderungen, Personas, …
  • Releases, Releasepläne, Release-Notes, …
  • Kapazitätsplan
  • Risiko-Management-Plan
  • diverse Charts

Schritt 3: Dinge, die ein Product Owner nicht tun sollte

Klare Aufgaben und Verantwortlichkeiten? Prima! Es ist aber ebenso wichtig, dass der Product Owner und auch die anderen Projektbeteiligten genau wissen, welche Dinge ein Product Owner nicht tun sollte. Hierzu ist es sehr hilfreich, sich mit dem Agile-Mindset zu beschäftigen und sich Gedanken über die Zusammenarbeit zwischen Product Owner, Development Team und Scrum Master zu machen. Eine sehr kurzweilige und effiziente Kreativitätstechnik, die sich dazu anbietet, ist das "Brainstorming paradox“. Aus der Sicht des Product Owners stellt man dabei eine provokante Frage, z. B. "Wie bringe ich das Development-Team gegen mich auf?".

Zu den typischen Fehlern zählen unter anderem folgende Punkte. Der Product Owner ...

  • ist nicht verfügbar,
  • macht klassisches "Command & Control Mikromanagement",
  • versteht sich als Chef des Teams,
  • mischt sich in die technische Lösungsdiskussion ein,
  • übernimmt oder beeinflusst Aufwandsschätzungen.

Schritt 4: Für Ermächtigung und Transparenz sorgen

Der Product Owner benötigt eine verbindliche Legitimation, d.h. die Unterstützung und volle Ermächtigung des Managements, damit er die Rolle erfolgreich ausfüllen kann. Besonders wichtig ist die Entscheidungsbefugnis bezüglich der genauen Formulierung von Anforderungen und deren Priorisierung.

Die Ergebnisse der Schritte 1 bis 3 werden in einer Excel-Tabelle zusammengefasst. Das Management und der Kunden werden zu einem 2-stündigen Termin eingeladen. In diesem Term werden Ergebnisse präsentiert und direkt Anmerkungen und Ergänzungen übernommen. Zum Ende des Termins sollte Konsens über die Product Owner Aufgaben bestehen. Allen Beteiligten sollte dann klar sein, dass der Product Owner seiner Verantwortung nur dann gerecht werden kann, wenn er dazu die notwendige Bevollmächtigung und Zeit (Kapazität) bekommt. Um die Bevollmächtigung nicht nur zu erteilen, sondern auch zu dokumentieren und zu kommunizieren werden aus der Excel-Tabelle zwei Poster erzeugt und mehrfach aufgehängt. Ein Poster illustriert die Aufgaben und Verantwortlichkeiten, das andere visualisiert die Dinge, die ein Product Owner nicht tun sollte!

Fazit

Diese vier Schritte helfen dabei, die Rolle des Product Owners zu definieren und für den notwendigen Spielraum zu sorgen. Da sich die Randbedingungen im Laufe der Zeit natürlich ändern können, sollte man auch die Ausgestaltung der Product Owner Rolle regelmäßig hinterfragen.

Ausführliche Informationen und hilfreiche Fragestellung bietet unser Whitepaper "HowTo - Starten als Product Owner". Das zugehörige Product Owner Poster dient dazu, die Ergebnisse zu visualisieren und zu kommunizieren.

Download Scrum Product Owner Whitepaper
Über itemis

Die itemis AG ist ein unabhängiges IT-Beratungs­unternehmen, das leistungsfähige Software für Unternehmens­anwendungen, eingebettete Systeme und mobile Applikationen entwickelt – und über diese Themen bloggt.