Kooperation lautet das Schlüsselwort in der agilen Projektentwicklung. Team und Product Owner arbeiten deshalb im Idealfall eng, gewinnbringend und unterstützend zusammen. Manchmal kommt es dann vor, dass Zuständigkeiten des Product Owners ausgelagert werden. Aber ist das wirklich sinnvoll? Oder werden geteilte Zuständigkeiten der PO-Funktion eher zum Problem? Sollte ein Product Owner gar keine Aufgaben delegieren? Mit diesen Fragen befassen wir uns im Folgenden.
Welche Aufgaben hat der Product Owner?
Um zu verstehen, warum ein Product Owner nach Möglichkeit keine oder nur wenige Zuständigen abgeben sollte, definieren wir zunächst, wofür er oder sie überhaupt zuständig ist.
Der Product Owner nimmt eine bedeutende Rolle in der Projektentwicklung nach Scrum ein. Er ist für den unternehmerischen Erfolg eines Projekts verantwortlich. Er trägt dafür Sorge, dass eine App/Website/Software im Sinne des Teams und de*r Kund*in funktioniert und den größtmöglichen Mehrwert (oder value) bietet. Somit verwaltet er auch das finanzielle Budget eines Projekts. Um das alles zu zu gewährleisten, ist ein PO in der Regel für strategische Entscheidungen zuständig.
In diesem Rahmen übernimmt er folgende Aufgabengebiete:
- Benchmarking und Marktanalysen
- Wettbewerbsrecherche: Welche Konkurrenzangebote gibt es und was bieten diese den Nutzer*innen? Was leiten wir daraus für unser Projekt ab?
- Field study: Was tut sich auf dem Markt? Welche branchennahen Produkte gibt es und wie können sich diese auf das eigene Produkt auswirken?
- Umfeldanalyse: Welche gesellschaftlichen/technologischen/rechtlichen/wirtschaftlichen Faktoren haben einen Einfluss auf Kund*innen/Partner*innen/externe Dienstleister*innen?
Diese Rechercheobjekte spielen ganz zu Anfang des Projekts eine große Rolle. Die Ergebnisse bestimmen mit, in welche Richtung sich das Projekt entwickeln soll und welche Parameter dafür nötig sind.
2. Formulierung von Product Vision und Product Goal
- Zielgruppe: An wen richtet sich das Produkt?
- Bedarf: Welche Wünsche/Bedürfnisse/Probleme hat diese Zielgruppe und inwieweit kann das Produkt diese erfüllen?
- Produkteigenschaften: Welche Eigenschaften muss das Produkt dafür mitbringen?
- Nutzen: Welchen Nutzen hat es damit für Kund*innen und Unternehmen?
Diese Fragen sind die Basis-Fragen bei der Entwicklung eines Product Goals und einer Product Vision. Auch hierum kümmert sich vor allem der PO. Dabei bildet die Product Vision die große, langfristige Vision eines Unternehmens/Mega-Projekts. Das Product Goal ist die nächstkleinere Zieleinheit, ein festdefiniertes Ziel für ein einzelnes Projekt oder Feature.
Beispiel für eine Product Vision: Unsere Dating-App soll Menschen auf der ganzen Welt verbinden und unser Unternehmen an die Spitze auf diesem Markt bringen.
Beispiel für ein Product Goal: Unsere erste Version der App soll Menschen auf dem deutschsprachigen Markt den sicheren, schnellen Austausch von Flirtbotschaften ermöglichen.
Der Product Owner ist dafür verantwortlich, ein eindeutiges und umsetzbares Product Goal zu formulieren und – ganz wichtig – es dem Team so zu vermitteln, dass alle es verstehen und den Nutzen erkennen. Das ist eine der wichtigsten Grundlagen für effizientes Arbeiten nach Agile.
3. Entwicklung der Roadmap
- Welche Funktionen sind notwendig, um das bestmögliche Produkt zu erzielen?
- Wann sollte davon welches Feature realisiert werden?
- Bis wann kann das Gesamtprojekt fertiggestellt werden?
Die Roadmap bietet einen Leitfaden, der natürlich abhängig von den normalen Schwankungen und Veränderungen während der Projektentwicklung flexibel ist. Sie ist trotz aller Flexibilität eins der wichtigsten Tools, um den Projekterfolg zu garantieren. Der Product Owner beschäftigt sich hier vor allem mit Fragen der Liefertermine und Priorisierung von einzelnen Aufgaben. Updates und Releases werden hier so genau wie möglich eingeplant. Auch bei der Roadmap muss der PO dafür sorgen, dass das Team sie kennt und anerkennt.
4. Anlegen und Managen des Product Backlogs
- Welche Anforderungen an das Produkt sind definiert worden?
- Welche Fehlerquellen wurden erkannt und aus dem Weg geräumt?
- Welches neue Wissen hat das Projekt hervorgebracht, welche Ideen, Ergebnisse und Erkenntnisse?
- Welche strukturellen Aufgaben sind im Rahmen des Projekts angefallen – z. B. technische Neuerungen oder Änderungen bezüglich der Infrastruktur im Team?
Diese vier Bereiche bilden den Kern des Product Backlogs. Das Backlog wiederum ist neben der Roadmap ein essentieller Teil von Scrum. Der Product Owner ist dafür zuständig, ein Backlog für jedes Produkt anzulegen und es aktuell zu halten. Dadurch wird es kontinuierlich erweitert und detaillierter ans Projekt angepasst, weshalb dieser Prozess im Scrum Refinement genannt wird. Auch sollte der PO unbedingt Sorge dafür tragen, allen Projektbeteiligten Einsicht in das Backlog zu geben, d. h. einen für alle zugänglichen virtuellen Ort dafür schaffen.
Wichtig ist, dass Sie sich als Product Owner vorher mit den Teammitgliedern darüber verständigen, was in welchem Zeitraum machbar ist. Nur so ist sichegrestellt, dass die Backlog-Einträge wirklich realistisch in den zugehörigen Sprints umzusetzen sind. Auch „dürfen“ (laut Scrum-Guide) andere Teammitglieder als der PO selbst Einträge ins Backlog vornehmen. Allerdings sollte dies maximal 10 % ihrer Arbeitszeit in Anspruch nehmen. Für das Einhalten der Scrum-Regeln ist jedoch nicht der PO, sondern der Scrum Master zuständig.
5. Kommunikation mit Externen
Da der Product Owner für den Gesamterfolg des Projekts zuständig ist, ist er auch die erste Anlaufstelle für externe Projektbeteiligte. Das können Lieferant*innen, Auftraggeber*innen oder Geschäftspartner*innen sein. Als Bindeglied zwischen Team und externen Interessensgruppen muss der Product Owner stets Anforderungen von außen mit intern geplanten Aufgaben abgleichen und ggf. aufeinander abstimmen. Er kommuniziert den Projektverlauf und setzt finanzielle sowie zeitliche Limits in Abstimmung mit der Auftraggeber*in eines Projekts. Der Product Owner ist also quasi das Sprachrohr in einer jeden Produktentwicklung.
6. Done oder nicht done? – Überprüfung der vollbrachten Aufgaben
Ganz wichtig: Ein Product Owner überprüft die vom Team umgesetzten Anforderungen laut Product Backlog, nimmt diese ab oder fordert, wenn notwendig, eine Überarbeitung ein. Das geschieht nach jedem Sprint im Review und kann mit Hilfe der Definition of Done erleichtert werden.
Diese legt vorab fest, welche Kriterien und Tasks erfüllt sein müssen, damit ein Feature als „done“ betrachtet wird. Auch hier ist wichtig, dass von Vornherein ein Konsens zwischen Team und Product Owner darüber besteht, wann eine Aufgabe als erfüllt gilt und wann sie noch zu bearbeiten ist. So wird auch im Review das Konfliktpotenzial minimiert und der Workflow im neuen Sprint verbessert.
Welche Aufgaben hat der Product Owner NICHT?
Der Product Owner hat also nach außen hin die größte Verantwortung in einem Projekt. Dennoch sind seinem Zuständigkeitsbereich Grenzen gesetzt, die Scrum auch vorgibt.
- Der Product Owner ist kein „Chef“
Ein Product Owner ist kein*e Teamleiter*in. Product Owner sind zwar dafür zuständig, den Anforderungskatalog auf Erfüllung durch Entwickler*innen und Co zu überprüfen. Sie haben jedoch weder die Pflicht noch das Recht dazu, wie auch immer gearteten Druck auf einzelne Teammitglieder auszuüben, wenn diese ihrer Aufgabe nicht nachkommen. Da sie trotzdem dafür geradestehen müssen, wenn ein Projekt in die Hose geht, sind sie umso mehr auf die Unterstützung kompetenter Teamleiter*innen angewiesen oder – bei kleinen Teams – auf die Eigenverantwortlichkeit aller Mitarbeitenden.
2. Der Product Owner stellt nicht das Team zusammen
Gute Product Owner weisen eine hohe unternehmerische Kompetenz auf. Fachlich sind sie den ausführenden Teammitgliedern normalerweise unterlegen. Es ist also wenig sinnvoll, wenn der Product Owner sein Spezialist*innen-Team allein zusammenstellt. Hier kommen die Fachmenschen zum Zug und der PO sollte auf deren Rat und Expertise setzen, damit ein Team entsteht, das allen Anforderungen an das Produkt gerecht werden kann.
3. Der Product Owner übernimmt nicht die Sprintplanung der Teams
Obwohl der Product Owner in der Roadmap einen ersten Vorschlag für den zeitlichen Aufwand der einzelnen Aufgaben vorgeben kann, liegt es an den Teams, die realistische Planung vorzunehmen. Auch das ist nur logisch – denn niemand kann den Aufwand einer Sache und die eigene velocity besser einschätzen als ein erfahrenes Fachteam. Die Vergabe von Story Points ist also ebenfalls Aufgabe des Fachteams. Deshalb sollte der Product Owner dessen Schätzung annehmen und das Product Backlog danach ausrichten.
4. Der Product Owner verteilt keine Aufgaben
Der Product Owner hat das Recht, im vereinbarten Rahmen Ergebnisse vom Team einzufordern. Es ist aber nicht sein Ressort, die einzelnen Aufgaben im Team zu verteilen. Das übernimmt das Team eigenverantwortlich, da es auch hier viel mehr Expertise aufweist als der Product Owner. Wenn sich Product Owner und Team gut kennen, kann hier natürlich ein Austausch konstruktiv sein. Die Entscheidung liegt aber immer im Team selbst.
5. Der Product Owner moderiert nicht das Daily Scrum
Product Owner haben einen festen und wichtigen Platz in regelmäßigen Meetings wie Sprintplanung und Review. Anders ist es beim Daily. Hier kann der Product Owner bei Bedarf gerne teilnehmen, um sich über Aufgaben, Errungenschaften und Probleme der täglichen Arbeit zu informieren, er kann das Daily allerdings auch an das Team abgeben und nicht teilnehmen.
6. Der Product Owner ist nicht Mitglied des Entwickler*innen-Teams
Wie schon gesagt: Ein Product Owner vertritt die Anforderungen an ein Produkt, vor allem von Seiten der Auftraggeber*innen. Er ist in der Regel kein Fachspezialist und sollte auch nicht an der ausführenden Produktentwicklung beteiligt sein. Durch diese Grenze kann er den objektiven Blick auf das Produkt und seine wichtigsten Parameter behalten.
Und warum sollte ein Product Owner nun nicht alles delegieren?
Angesichts der enormen Verantwortung eines POs verwundert der Wunsch nicht, ein kleines bisschen davon abzugeben und auf andere zu übertragen. Das ist verständlich, aber leider auch oft sehr ineffektiv. Scrum definiert die Aufgabe des Product Owners als Verantwortungsbereich einer einzelnen Person. Und das hat vor allem einen guten Grund:
Mehrere Product Owner führen zu Missverständnissen. Die Schnittstelle zwischen internen und externen Projektbeteiligten sollte aber so transparent wie möglich gehalten werden. Es ist daher essentiell, dass nur eine Person als Product Owner diesen Part übernimmt.
Der Product Owner muss den Überblick über das Projekt behalten, um einen reibungslosen Austausch zu ermöglichen. Informationen dazu kann und muss er sich aus den Teams holen. Doch damit ein vollständiger und unmissverständlicher Informationsfluss zwischen Team und Externen gegeben ist, ist ein Product Owner als einzige Quelle dafür die sinnvollste Option.
Das heißt nun nicht, dass er jede seiner im Scrum-Guide festgehaltenen Aufgaben völlig alleine ausführen muss. Rein interne Aufgaben, wie z. B. das Eintragen einzelner Anforderungen ins Backlog, können auch von anderen Teammitgliedern übernommen werden – jedoch nur in Absprache mit dem PO und nur, solange es sie nicht in größerem Maße von ihren eigentlichen Aufgaben abhält.
"Jeder PO ist ein Mensch. Und jedes Entwicklungsteam besteht aus Menschen mit verschiedenen Hintergründen, Expertisen und Skills."
Wann der Product Owner (auch ohne Zuständigkeit) mitmischen kann
Umgekehrt gibt es natürlich auch die o. g. Aufgabenbereiche, in denen der Product Owner eigentlich fehl am Platze ist – wie das Verteilen der Aufgaben oder die Vergabe von Story Points.
Das große Aber lautet: Jeder PO ist ein Mensch. Und jedes Entwicklungsteam besteht aus Menschen mit verschiedenen Hintergründen, Expertisen und Skills. Sollte nun ein Product Owner zufällig aus einem relevanten Fachbereich der Entwicklung kommen, spricht nichts dagegen, wenn er auch in diesen Fragen zu Rate gezogen wird. Auch hier gilt jedoch wieder: Das greift nur, insoweit es den Product Owner nicht von seinen „Eigentümer-Aufgaben“ abhält und das Team damit einverstanden ist.
Darüber hinaus spielen natürlich auch die äußeren Umstände im Unternehmen eine Rolle. In Ausnahmesituationen kann es notwendig sein, dass ein PO auch an teamspezifischen Stellen „mit anpackt“, damit ein Feature erfolgreich implementiert werden kann. Scrum ist nämlich auch beim Thema „Product Owner und seine Zuständigkeiten“ vor allem eins – agil. Die Richtlinien, die wir in diesem Artikel ausführlich dargestellt haben, sind als sinnvoller Rahmen zu verstehen. Was ein Team daraus macht, liegt an ihm selbst.
Das gilt natürlich auch für Ihr Team. Wie setzen Sie die Aufgabengebiete des Product Owners um? Halten Sie sich strikt an den Scrum-Guide oder haben Sie für sich funktionierende Abwandlungen davon entdeckt? Welche Scrum-Rollen haben sich in Ihrem Unternehmen etabliert? Alles Fragen, denen es sich lohnt, nachzugehen. So stellen Sie fest, was in Ihrem Rahmen schon gut funktioniert und wo Sie den Workflow noch weiter verbessern können.
Bei Ambient arbeiten wir längst aus voller Überzeugung nach Scrum. Für uns sind die Rollen von Scrum Master, Product Owner und Co. eindeutig geklärt und wir haben Sie in unseren Workflow bestens integriert. Aber natürlich weichen auch wir dann vom Scrum-Guide ab, wenn es in besonderen Situationen für unseren Erfolg sinnvoll ist.
Haben Sie Fragen zur agilen Arbeit bei Ambient? Dann schreiben Sie uns! Wir erzählen Ihnen gerne, wie wir arbeiten und was sich bei uns als Erfolgsrezept etabliert hat. Oder lesen Sie unseren Artikel "10 wichtige KPIs für Product Owner".
