#440 Scrum-Konferenz: Die Rolle des Product Owners
Im heutigen Beitrag widmet sich der bekannte Scrum-Autor Roman Pichler der Rolle des Product Owners.
Bei der Einführung von agilen Projektmanagement-Methoden stellt die Rolle des Product Owners immer wieder eine Herausforderung dar und führt zu Schwierigkeiten. Die Rolle geht über das klassische Produktmanagement hinaus. Häufig besteht schon eine Schwierigkeit in der Besetzung der Rolle. Wer soll die Rolle des Product Owners übernehmen? Marketing, ein Programmierer oder gar der Kunde?
Die Hauptaufgabe des Product Owners ist es, den Erfolg einer Produkteinführung/-weiterentwicklung sicherzustellen. Er übernimmt Verantwortung für das Produkt. Projekt-/produktabhängig ist zu entscheiden, wer am sinnvollsten diese Rolle einnimmt. Der Product Owner ist weit mehr gefordert als ein klassischer Produktmanager. Er übernimmt zusätzlich Aufgaben eines klassischen Projektleiters. Es besteht daher immer die Gefahr einer Überlastung. Seine Rolle ist aber keine Zusammenfassung von Produktmanagement und Projektleitung. Er übernimmt zwar Aufgaben der strategischen Projektleitung, aber andere Leitungsaufgaben wandern direkt ins Team. Der Product Owner muss Kunden und Markt verstehen. Er sollte eine gewisse Technologieaffinität mitbringen, braucht aber nicht unbedingt einen detaillierten Entwicklungshintergrund.
Scrum sagt sehr wenig, was vor dem ersten Sprint passiert.
Aber was sollte vorab in der Product Vision definiert sein?
- Die Zielgruppe
- Welche Bedürfnisse sollen adressiert werden?
- Die wichtigsten Produktattribute/Features (3-5 top Features, der Rest folgt später)
- Wie verhält sich das Produkt zum Wettbewerb?
- Wie steht es im eigenen Produktportfolio?
- Wie sieht es mit der Machbarkeit (technisch und vertrieblich) aus?
Die Product Vision beschreibt die Essenz des künftigen Produkts und sollte von allen (Team und Stakeholdern) mitgetragen werden. Sie ist Grundlage für eine Investitionsentscheidung.
Im agilen Kontext sollten sich aber Umfang und Aufwand für die Product Vision noch in Grenzen halten.
Um die Product Vision im Team zu verankern empfiehlt sich:
- Das Team an der Enstehung der Product Vision zu beteiligen.
- Das Projekt langsam/organisch wachsen lassen. Mit einem kleinen Team beginnen und dann das Team splitten und erweitern.
Das Backlog sollte vor dem ersten Sprint stehen. Es sollte auf alle für den Produkterfolg erforderlichen Inhalte fokusieren. Das Backlog ist keine Wunschliste oder Ideensammlung. Das Backlog sollte priorisieren, adäquat detailliert sein (abhängig von der Priorität, wenig priore Dinge können anfangs noch skizzenhaft sein) und die priorisierten Einträge sollten abgeschätzt sein. Es ist ein dynamisches Dokument, ein emergentes Artefakt, das sich im Laufe der Zeit verändert.
Jedes Produkt hat EIN Produkt-Backlog. Jedes Feature-Team kann sich um einen Abschnitt eines Produkt-Backlogs kümmern. Bei Komponenten-Teams wäre das Backlog entsprechend umzuarbeiten. In Scrum versucht man deswegen Komponenten-Teams weitgehend zu vermeiden.
Das Backlog sollte die Komplexität reduzieren (insbesondere was den Featureumfang betrifft). Überspezifizierung ist zu vermeiden. Es sollte ein einfaches Tool sein. Die Inhalte sollten zunächst grob sein und strukturiert werden.
Idealerweise wird das Backlog im Teamraum aufgehängt. Roman Pichler schwört dabei auf Papierkarten. Ein Backlog, das nicht mehr an der Wand Platz hat, sollte hinterfragt werden. Weniger ist mehr.
Bei komplexeren Produkten kann zusätzlich elektronische Unterstützung z.B. in Form eines Spreadsheets sinnvoll sein.
Jedes Team-Mitglied kann Einträge zum Backlog beitragen, aber die Priorisierung liegt beim Product Owner. Er muss authorisiert sein auch „nein“ zu sagen um eine Feature-Soup (im Sinne Tom DeMarcos) zu verhindern. Etwas 10% des Teamaufwands sollten in die Pflege des Backlogs investiert werden. Hierzu empfiehlt Roman wöchentliche Pflege-Workshops.
Tasks, also Backlog-Einträge, sollten so formuliert sien, dass sie die Aufwandsabschätzung für einen Sprint und die Selbstorganisation im Team ermöglichen. Also am besten klein halten und spezifisch bleiben. Auf Basis der Tasks committed sich das Team.
Zur laufenden Kontrolle innerhalb eines Sprints kommt dann im Team das Sprint-Burndown-Diagramm zum Einsatz.
Tags: Backlog, Product Owner, Product Vision, SCRUM