Nachdem wir Euch den Projektleiter im Artikel Was macht ein Projektleiter eigentlich den ganzen Tag? vorgestellt haben, kümmern wir uns in diesem Artikel um die Rolle des „Product Owner“ (kurz: PO). Dabei betrachten wir den PO wie er nach Scrum definiert ist und sich in unseren Projektalltag einfügt.

Kurz vorweg: Bei Scrum handelt es sich um ein agiles Vorgehensmodell des Produkt- und Projektmanagements, das ursprünglich aus der agilen Softwareentwicklung stammt.

Der Product Owner ist eine (zentrale) Rolle des Scrum Teams. Wie der Name schon vermuten lässt, ist er verantwortlich für das Produkt im Sinne eines Produktmanagers. Im Scrum Guide heisst es

„Der PO ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts“

Definition aus dem Scrum Guide 2020

„Wert“ meint hier den Nutzen, wie auch immer dieser für das jeweilige Produkt definiert ist. Also dem, was sich die Auftraggeber von der Durchführung des Projekts versprechen. Hier sollte man in einem guten Projektprozess zumindest in der Zieldefinition bzw. dem Projektsteckbrief etwas finden.

Die Aufgaben

Der PO teilt Anforderungen der Stakeholder in Epics auf und formuliert anschließend Userstories zu deren Umsetzung. Dabei können natürlich die Anforderungen von einem spezialisierten Anforderungsmanager erarbeitet werden…
Im klassischen Projektmanagement entspricht das Arbeitspaket am ehesten einer Userstory, allerdings mit einem anderen Fokus. Was genau Userstories und Epics sind und was man bei der Erstellung beachten sollte, stellen wir in einem weiteren Artikel vor.

Userstories und Epics schreibt der Product Owner in das Product Backlog. Das ist im Endeffekt eine priorisierte Liste, die meistens in einem spezialisierten Ticketsystem wie Jira von Atlassian abgebildet wird. Das Product Backlog ist für den PO ein Arbeitstool! Hier findet man sowohl für die Entwicklung fertige Userstories (Stichworte: „Ready for refinement“ bzw. „Ready for planning“), als auch solche an denen der Product Owner noch inhaltlich arbeitet. Oben in der Liste stehen die fertigen Userstories. Unten findet man teilweise nur noch Überschriften als Reminder, was noch zu tun ist. Das Product Backlog ist auch niemals fertig sondern spiegelt immer den aktuellen Stand der Konzeption des Produkts durch den Product Owner wieder. Ganz im Sinne der Agilität. Außerdem ist er für die Priorisierung des Product Backlogs zuständig. Dabei stehen die Userstories, die den größten Nutzen für das Produkt liefern weiter oben.

Wesentlicher Bestandteil des agilen Vorgehens ist: So viel spezifizieren, wie nötig aber so wenig wie möglich, um alle Kraft in die Entwicklung zu stecken. Dabei ist es ein akzeptiertes Risiko, dass gelegentlich Informationen in den Userstories fehlen, obwohl sie bereits Gegenstand des aktuellen Sprints sind. Als „Sprint“ wird in Scrum ein Zeitraum von 2 bis 4 Wochen bezeichnet. Ein Zyklus, bzw. eine Iteration besteht immer aus einem Sprint. Aus diesem Grund muss der Product Owner während des Sprints für das Entwicklungsteam für Nachfragen zur Verfügung stehen. Auch nötige Entscheidungen muss er möglichst zeitnah herbeiführen oder treffen.

Regelmeetings an denen der Product Owner teilnimmt

Neben der planerischen und konzeptionellen Arbeit im Product Backlog nimmt der Product Owner an mehreren Regelmeetings des Scrum-Prozesses teil. Diese können ein oder mehrmals pro Sprint stattfinden:

Im Refinement (ein- oder mehrmals pro Sprint) stellt der Product Owner die neu fertig gewordenen Userstories dem Entwicklungsteam vor und klärt eventuell aufkommende Fragen der Entwickler. Neue Erkenntnisse aus dem Meeting werden von ihm in die entsprechende Userstory übernommen. Es ist Aufgabe des Product Owners dafür zu sorgen, das immer genug Userstories besprochen sind, damit die Entwicklung nicht ins Stocken gerät.

Sprintplanning (einmal pro Sprint – Sprint Anfang)

Im Sprintplanning legt das Entwicklungsteam zusammen mit dem Product Owner den Inhalt des nächsten Sprints fest. Durch die Priorisierung der Userstories im Product Backlog ist die Reihenfolge festgelegt in der Funktionen entwickelt werden. Das Entwicklungsteam entscheidet allerdings wie viele Userstories im nächsten Sprint geleistet werden können. Diese Entscheidung trifft das Team in Abhängigkeit des Umfangs der entsprechenden Userstories. Die Userstories, die für den kommenden Sprint geplant sind, werden aus dem Product Backlog in das Sprint Backlog übernommen. Das Sprint Backlog ist das Arbeitstool des Entwicklungsteams. Es entspricht quasi einem Kanban Board, also einer Listendarstellung mit Statusinformationen (z.B. „Todo“, „in progress“, „in test“, „done“, …). In manchen Teams wird das Sprint Backlog über eine Pinnwand mit Karteikarten realisiert. Das gibt dem Ganzen einen ganz besonders agilen Touch!

Sprint Review (einmal pro Sprint – Sprint Ende)

Im Review präsentiert das Entwicklerteam dem Product Owner die Ergebnisse, also die umgesetzten Userstories. Dabei ist es Aufgabe des Product Owners das Ergebnis, wenn es mit dem Inhalt der Userstories überein stimmt, abzunehmen. Alternativ kann er die Abnahme verweigern, so dass die Userstories ggf. im nächsten Sprint erneut angegangen werden müssen. Am Ende des Reviews wird der Sprint durch den Product Owner geschlossen. Unfertige Userstories werden zurück ins Product Backlog oder den nächsten Sprint übernommen und die Teamvelocity festgehalten. Die Teamvelocity ist der Messwert für die Teamleistung im Scrum und kann für die Zeit- und Ressourcenplanung verwendet werden.

Sprint Retrospektive (meistens einmal pro Sprint – oft am Ende)

An der Retrospektive kann der Product Owner als Teil des Scrum Teams teilnehmen. Dabei geht es um den kontinuierlichen Verbesserungsprozess von Scrum, der elementarer Bestandteil des Vorgehensmodells ist. Ziel des Termins ist es Ereignisse aus dem letzten Sprint, die gut gelaufen sind, zu identifizieren und zukünftig gezielt zu forcieren. Ereignisse, die im letzten Sprint schlecht gelaufen sind sollen im nächsten Sprint durch Maßnahmen zu vermeiden.

Der Product Owner im klassischen Projektkontext

Scrum konzentriert sich auf den Entwicklungsprozess und aus Sicht der Planung nur auf einen Zeitraum von 2 bis 4 Wochen. Dadurch scheint alles, was über einen Sprint hinaus geht ungeplant zu sein. In der Praxis sind natürlich auch im agilen Vorgehen Budget und Zeit endliche Ressourcen. Aus diesem Grund muss/ kann/ sollte klassisches Projektmanagement auch im Agilen angewendet werden. Doch wie sortiert sich hier der Product Owner ein? Die Antwort darauf heißt: es kommt darauf an, wie die Organisation sich aufgestellt hat!

PO & PL in einer Person

Ich habe schon funktionierende Setups gesehen bei denen der Product Owner auch ein ausgebildeter Projektleiter war und neben den von Scrum beschriebenen Tätigkeiten das klassische Projektmanagement quasi nebenbei mit erledigt hat. Das ist im Übrigen normalerweise die Art, wie ich in Projekten arbeite. Da „agile“ Kunden mich nicht als Projektleiter beauftragen, sondern als Product Owner erledige ich einfach beide Aufgabenfelder, falls der Kunde keinen Projektleiter stellt.

PO & PL als Team

Aber auch die Kombination aus einem klassischen Projektleiter und einem Product Owner habe ich schon erfolgreich arbeiten gesehen. In der Kombination tritt der Projektleiter quasi als Stakeholder für den Product Owner auf und stellt zeitliche Anforderungen. Im Gegenzug liefert der Product Owner für den Projektleiter die Aufwandsschätzung und Velocity des Entwicklungsteams in Storypoints. Auf diese Weise kann der Projektleiter eine Zeit-, Budget- und Ressourceneinsatzplanung machen kann.

Scrum Master & PO = PL

Dann habe ich schon die „Lösung“ gesehen, dass der klassische Projektleiter durch das Gespann Product Owner und Scrum Master ersetzt wurde. Dabei fielen alle Controllingaufgaben dem Scrum Master zu und alle planerischen Tätigkeiten musste der Product Owner erledigen. Diese Lösung hat meiner Meinung nach eher schlecht als recht funktioniert. Zum Einen wird der Scrum Master dadurch vom Projekterfolg direkt betroffen und erfüllt nicht mehr seine eigentliche Funktion im Scrumprozess. Was der Scrum Master eigentlich den ganzen Tag macht, erklären wir in einem anderen Beitrag. Außerdem hilft es in meinen Augen nicht Planung und Controlling auf zwei Köpfe zu verteilen, weil damit der PDCA-Zyklus (Plan, Do, Check, Act) nicht gut funktioniert.

Fazit

Die Rolle des Product Owners ist spannend, kommunikativ, abwechslungsreich und vor allem geeignet sich selbst zu verwirklichen. Schaut man sich die Tätigkeitsfelder des Product Owners an erkennt man viele Aufgaben, die auch der klassische Projektleiter leisten muss. Andersherum ist das Spektrum des Projektleiters (aus meiner Sicht) thematisch vielfältiger. Wobei das nicht bedeuten soll, dass der Product Owner weniger macht, als ein Projektleiter! Der Product Owner ist viel dichter an der Umsetzung als ein klassischer Projektleiter und arbeitet als Scrum Teammitglied unmittelbar mit am Produkt.

Die Rolle des Product Owners kann sehr interessant sein für uns „technische Projektleiter“, deren Herz zwar für das klassische Projektmanagement schlägt, die aber früher selbst als Ingenieure bzw. Informatiker an der Lösung gearbeitet haben und diese Tätigkeit eigentlich auch nicht missen wollen.