Ich habe mich in letzter Zeit mit dem agilen Projektmanagement nach Scrum beschäftigt. Und das endete damit, dass ich letzte Woche als CSPO zertifiziert wurde. Das steht für „Certified Scrum Product Owner“.

Viele Leute haben etwas vom „Scrum Master“ gehört und wundern sich vielleicht jetzt, was ein „Product Owner“ bei Scrum ist. Mein Trainer Mitch Lacey hat die drei Scrum-Rollen schön mit einer Analogie erklärt:

  • Das Scrum Team hat er mit einem Automotor verglichen. Es erarbeitet die Projektergebnisse.
  • Der Scrum Master ist das Öl, mit dem der Motor effizient und performant läuft. Der Scrum Master ist ein Coach, der das Team dabei unterstützt, effizienter zu werden, die Scrum-Prozesse einzuhalten und die geeigneten Tools anzuwenden.
  • In diesem Bildnis ist der Product Owner das Navigationssystem und die Tankstelle. Der Product Owner gibt die Richtung an und stellt die Betriebsmittel (=Budget) zur Verfügung.

Der Product Owner ist dabei gegenüber dem Auftraggeber alleinverantwortlich für die Projektergebnisse.  Im englischen Sprachraum sagt man, er sei „a single wringable neck“. Das ist unmissverständlich. Aber genau diese klar geregelte Verantwortlichkeit fehlt doch in vielen Projektorganisationen, in denen nicht selten ganze „Teams“ von Projektmanagern sich die Verantwortung teilen. Der Product Owner im Scrum-Umfeld ist also die Rolle, die dem klassischen Projektmanager entspricht, sofern er fachlich kompetent und eben alleinverantwortlich ist.

Warum aber heisst das Product Owner und nicht Projekt-Manager? Das Produkt ist das Ergebnis des Projekts. Und Scrum stellt das Ergebnis voran. Dagegen ist das Projekt der Weg, der zu diesem Ergebnis geführt hat. Die Scrum-Terminology unterstreicht hier nochmal, dass vor allem das Resultat zählt. Im kommerziellen Umfeld ist nicht der Weg das Ziel…

Und welche Eigenschaften muss ein Product Owner haben? Für das Scrum Team ist der Product Owner der Allwissende. Was auch immer das Team für fachliche Fragen hat, der Product Owner beantwortet sie. Er muss alle fachlichen Anforderungen kennen, verstehen und auch priorisieren. Dieses Wissen muss er mit den Stakeholdern erarbeiten und nutzt dazu verschiedene Techniken. Diese Techniken sind gar nicht Scrum-spezifisch, sondern entsprechen durchaus dem Werkzeugkasten eines Business Analysten. Product Owner und Stakeholder dokumentieren die Anfordeungen durch sogenannte user stories, die zusammen das product backlog ausmachen. Weiterhin erstellt der Product Owner den Release-Plan, plant mit dem Team zusammen die einzelnen Entwicklungsphasen (sprints) und nimmt dem Team auch die Arbeitsergebnisse ab.