Scrum Reihe 3: Wie viel Product-Owner braucht ein Team?

Scrum ist inzwischen das wohl bekannteste Methoden-Framework im agilen Kontext und verbreitet sich zunehmend auch außerhalb der IT- und Software-Entwicklung.

Da fast alle Projekte der Faktor Zehn nach Scrum durchgeführt werden, kommt es in größeren Projekten auch immer wieder zu der Fragestellung, ob denn wirklich jedes Team einen eigenen Product-Owner benötigt. Kann denn nicht ein Product-Owner für mehrere Teams zuständig sein? Diese Frage bekommt  mit der Empfehlung aus dem letzten Artikel, eher kleinere und damit natürlich auch eher mehr Teams einzusetzen, besondere Bedeutung. Nicht nur, weil es einen finanziellen Unterschied macht, ob man fünf oder zehn Product Owner beschäftigen muss. Sondern auch, weil es durchaus schwierig sein kann, die erforderliche Anzahl an erfahrenen Personen zusammen zu bekommen, um alle Product-Owner-Stellen auch besetzen zu können.

Ohne die Bedeutung der anderen Scrum-Rollen schmälern zu wollen, ist doch der Product-Owner die Rolle im Scrum-Team, die den größten Einfluss auf den Gesamterfolg eines Vorhabens hat. Der Product-Owner ist verantwortlich für das Ergebnis. Laut Scrum-Guide beschreibt er oder sie die notwendigen Anpassungen und Erweiterungen am System, priorisiert diese und erklärt sie dem Entwicklungsteam. Das bedeutet aber auch, dass der Product-Owner sich mit den Stakeholdern abstimmt und deren Erwartungshaltungen managt, sich um das Budget kümmert und für die Akzeptanz seiner Entscheidungen im Unternehmen sorgen muss. Oft kommen nicht unerhebliche Berichtsaufgaben für das jeweilige Management dazu.

Die hier gestellte Frage, wie viel Produc- Owner ein Team braucht – 30%, 50% oder 100% – wird im Scrum-Guide nicht beantwortet (für den Scrum-Master im Übrigen auch nicht). Es gibt aber einen Hinweis zumindest in die Richtung, ob ein Team mehrere Product-Owner haben sollte: „Der Product-Owner ist eine einzelne Person, kein Komitee.“  Aber allein aus der Fülle der oben genannten Anforderungen an einen Product-Owner ergibt sich ziemlich klar: Es darf nur einen geben. Ein Product-Owner je Team, mit jeweils einem eigenen Backlog .

Erschwerend kommt noch hinzu, dass ein Product-Owner typischer Weise recht viel Zeit mit seinem Team verbringen muss. Nur so kann er dem Team die Anforderungen erklären und all die kleinen Entscheidungen treffen, die ständig anfallen und deren vorherige schriftliche Festlegung der reine Overkill wäre. Weil es aber so kleine Entscheidungen sind, würde ein Entwickler nicht zum Telefon oder zur E-Mail greifen, sondern es „erst mal so machen“. Dabei bleibt es dann meist, bis es negativ auffällt und relativ mühsam in einer eigenen Aufgabe wieder gerade gerückt werden muss.

Schreiben Sie einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*