Die Rolle des Product Owner bei Scrum

Scrum (Englisch für Gedränge) hat sich als die bekannteste Methode in der agilen Softwareentwicklung etabliert. Sie folgt einfachen Regeln und ist schlank organisiert. Scrum benötigt nur wenige Akteure, die bestimmte Rollen übernehmen: der Kunde, der Product Owner, der Scrum Muster und das Scrum Team. Der Product Owner hat eine führende Rolle im Scrum Prozess. Welche das ist und warum das so ist, beleuchtet dieser Beitrag.

In welchen Situationen ist Scrum als Methode für die Softwareentwicklung gut geeignet? Im Gegensatz zum Wasserfallmodell, welches die Phasen Analyse, Entwurf, Implementierung und Test linear durchläuft, ist Scrum deutlich flexibler. Aus dieser Perspektive sprechen zwei wesentliche Vorteile für den Scrum Prozess: Wenn während der Projektlaufzeit mit stark veränderlichen Anforderungen zu rechnen ist oder wenn die Anforderungen so aufteilbar sind, sodass sie unabhängig voneinander funktionieren können. Der Einsatz des Wasserfallmodels wäre sinnvoller, wenn das Softwareprodukt von Anfang an vollständig konzeptioniert sein muss oder wenn Änderungen am Projektinhalt als störend und lästig empfunden werden. Sind die Projektteams größer als acht Personen oder arbeiten die Mitglieder des Teams örtlich verteilt, kann Scrum seine Vorteile nicht entfalten.

Agile gesteuerte Projekte benötigen statt eines Projektleiters, den Scrum Master und einen Product Owner. Der Scrum Master schafft stabile Rahmenbedingungen für das Scrum Team und sorgt für einen stabilen und produktiven Output. Der Product Owner treibt das Projekt gemeinsam mit dem Kunden aus wirtschaftlicher Sicht voran. Beide ersetzen die Rolle des klassischen Projektleiters, der in dieser Form nicht mehr benötigt wird.

Die oben genannten Aspekte und das neue Rollenverständnis verlangt vom Product Owner spezielle Fähig- und Fertigkeiten. Welchen sind das?

Wofür ist der Product Owner verantwortlich?

Der Product Owner hat eine Vision des Produktes. Gemeinsam mit dem Product Manager entwickelt er aus dieser Vision eine Produktstrategie. Sobald die Strategie in seinen Grundfesten steht, extrahiert der Product Owner aus dieser ein Dokument, welches als Product Backlog bezeichnet wird. Das Product Backlog enthält eine Liste mit Anforderungen, die das Softwareprodukt erfüllen muss. Im Product Backlog stehen die wichtigsten Anforderungen ganz oben. Der Product Owner priorisiert die Anforderungen gemeinsam mit dem Kunden, sodass eine Reihenfolge entsteht. Er gestaltet somit Releases, das sind Softwarepakete, die in einer Reihe von Sprints, den Entwicklungsintervallen eines Scrum Prozesses, entwickelt werden. Abgeleitet von den Anforderungen entwickelt der Product Owner User Stories. Diese bestehen in der Regel aus einer markanten Überschrift und einem Text, der höchstens zwei bis drei Sätze lang ist. User Stories beschreiben den Leistungsumfang in kurzer und verständlicher Form. Sie bilden die Grundlage für die Entwicklung der Software während der Sprints. Nach einem Sprint präsentiert der Product Owner die Liefergegenstände dem Kunden.

Was zeichnet einen guten Product Owner aus?

Der Product Owner bekleidet viele Funktionen. In der Gestaltung eines Produktes schaut er wie ein Visionär weit in die Zukunft, er denkt strategisch. Als Macher treibt er das Projekt voran, als Führungskraft schafft er inhaltliche Rahmenbedingungen. Der Product Owner überprüft die Ergebnisse wie ein Controller, in dem er Zielabweichungen aufdeckt. Falls notwendig, kann er einen Kurswechsel am Ende eines Sprints erzwingen. Kommt es zu drastischen Änderungen während eines Sprints, kann er diesen sogar beenden. Der Product Owner ist ein guter Redner und besitzt emotionale Intelligenz. Er ist ein Teamplayer, der sich für sein Team starkmacht und in schwierigen Situationen mit Fingerspitzenggefühl agiert. Gegenüber dem Kunden zeichnet er sich durch Verhandlungsgeschick aus. Der Product Owner ist auch Sündenbock, da er für alle Fehlentwicklungen des Projektes verantwortlich gemacht wird.

 

2 Comments

  1. Sven | Projektmanagement Blog

    Hallo Daniel,

    gut zusammengefasst.

    Zu den User Stories würde ich aber eines noch ergänzen. Neben der prägnanten inhaltlichen Beschreibung, die ja darstellen was zu liefern ist, gehören dazu auch noch 3 – 4 Akzeptanzkriterien. Diese stellen sicher, dass der Erfolg auch messbar wird. Gleichzeitig kann man diese auch gleich wunderbar als Testkriterien heranziehen.

    Grüße
    Sven

    Reply
    1. Daniel (Post author)

      Hallo Sven, danke für den Hinweis. Natürlich hast Du Recht, Akzeptanzkriterien gehören zu einer guten Story! Gruß

      Reply

Leave a Comment

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

*