Scrum Master vs. Product Owner: Die Rollen im Vergleich

Ein Product Owner ist dafür verantwortlich, den Wert des Produkts zu maximieren und zu steuern, was ins Backlog kommt: das „Was“ und das „Warum“. Ein Scrum Master ist für die Wirksamkeit des Scrum Teams und dafür verantwortlich, wie das Team arbeitet: das „Wie“, nicht das „Was“. Wer die beiden verwechselt, erzeugt fast jede weitere Unklarheit rund um diese zwei Aufgaben.

Diese Verwechslung ist so verbreitet, dass sich Präzision von Anfang an lohnt, denn in der Praxis verschwimmen die beiden Aufgaben ständig. Mal ordnet ein Scrum Master das Backlog stillschweigend neu, weil der Product Owner zu langsam ist. Mal führt ein Product Owner das Daily Scrum wie ein Statusmeeting, weil ihm niemand etwas anderes gesagt hat.

Key Facts

• Der Scrum Guide 2020 hält fest, dass Scrum „drei spezifische Verantwortlichkeiten innerhalb des Scrum Teams definiert: die Entwickler, den Product Owner und den Scrum Master“. Diese Formulierung ersetzte den Begriff „Rollen“ aus früheren Ausgaben.
• Laut Guide ist der Product Owner „dafür verantwortlich, den Wert des Produkts zu maximieren, das aus der Arbeit des Scrum Teams entsteht“, während der Scrum Master „für die Wirksamkeit des Scrum Teams verantwortlich ist“.
• Ein Scrum Team besteht laut Scrum Guide 2020 „in der Regel aus höchstens 10 Personen“, klein genug, damit beide Verantwortlichkeiten innerhalb eines Teams liegen und nicht in einer Managementebene darüber.
• Large-Scale Scrum (LeSS) setzt genau einen Product Owner für alle Teams ein, die an einem Produkt arbeiten, mit der Begründung, dass ein auf mehrere Product Owner verteiltes Backlog die Prioritäten zersplittert.

Zwei Verantwortlichkeiten, nicht zwei Rollen

Die meisten Vergleiche dieser beiden Positionen beginnen am falschen Ende: mit einer symmetrischen Liste nach dem Muster „Der Scrum Master macht X, der Product Owner macht Y“, als stünden beide auf gleichen, parallelen Gleisen. Das tun sie nicht, und der Scrum Guide 2020 hat seine Formulierung genau deshalb geändert. Frühere Ausgaben nannten Product Owner, Scrum Master und Entwickler „Rollen“. Die aktuelle Ausgabe verwendet dieses Wort für keinen von ihnen. Sie sagt, Scrum „definiert drei spezifische Verantwortlichkeiten innerhalb des Scrum Teams“. Das ist eine bewusste Änderung, die viele konkurrierende Erklärtexte aus Gewohnheit noch immer falsch wiedergeben, indem sie auf „Rollen“ zurückfallen.

Die Wortwahl ist wichtig. „Rolle“ suggeriert eine Stellenbeschreibung: einen Satz von Aufgaben, die einer Person zugewiesen sind. „Verantwortlichkeit“ bedeutet etwas Engeres und Schwereres: Eine Person steht für ein Ergebnis ein, unabhängig davon, ob sie die Arbeit dahinter selbst erledigt hat. So gelesen ist der Unterschied zwischen diesen beiden Aufgaben keine Aufgabenliste mehr, sondern die Frage, wofür jeder geradesteht, wenn etwas schiefgeht.

Wenn Sie noch nicht genau wissen, wie Scrum als Framework zusammenhängt, sollten Sie das vor diesem Vergleich lesen, denn alles Folgende setzt den Sprint, die drei Artefakte und das kleine, selbstmanagende Scrum Team voraus, das es definiert. Beide Verantwortlichkeiten existieren nur innerhalb dieser Struktur. Ohne Scrum bedeutet keiner der beiden Titel noch etwas Konkretes.

Scrum Master vs. Product Owner auf einen Blick

Wofür der Product Owner tatsächlich verantwortlich ist

Laut Guide ist „der Product Owner außerdem für ein wirksames Product-Backlog-Management verantwortlich“. Das gliedert sich in vier konkrete Aufgaben: das Produktziel entwickeln und kommunizieren, Backlog-Einträge erstellen und kommunizieren, das Backlog ordnen und es transparent und verständlich halten. In eine reale Woche übersetzt wirkt diese Liste weniger wie Papierkram als wie eine Kette von Abwägungsentscheidungen.

Zwei Sätze im Guide leisten mehr, als man auf den ersten Blick meint. Der erste: „Der Product Owner kann die genannte Arbeit selbst erledigen oder die Verantwortung dafür an andere delegieren. Unabhängig davon bleibt der Product Owner verantwortlich.“ Ein Product Owner kann jemand anderen die eigentlichen User Stories schreiben oder den Intake-Prozess führen lassen. Die Verantwortlichkeit selbst kann er nicht abgeben. Er trägt also die Verantwortung, auch wenn er nicht selbst den Stift führt.

Der zweite: „Damit Product Owner erfolgreich sein können, muss die gesamte Organisation ihre Entscheidungen respektieren.“ Das ist keine Höflichkeit, sondern eine strukturelle Voraussetzung. Ein Product Owner, dessen Backlog-Reihenfolge von jedem überstimmt wird, der sich bei einem VP beschwert, ist für nichts wirklich verantwortlich, egal was auf seiner Visitenkarte steht. Wenn das in Ihrem Team passiert, ist der Titel Dekoration.

Wofür der Scrum Master tatsächlich verantwortlich ist

Die Verantwortlichkeit des Scrum Masters gliedert sich in den Dienst an drei verschiedenen Adressaten: dem Scrum Team, dem Product Owner und der Organisation. Diese Dreiteilung übersieht man leicht, wenn man den Scrum Master nur als „die Person, die das Standup leitet“ betrachtet.

Beachten Sie, was nicht auf dieser Liste steht: Statusberichte ans Management schreiben, einen Liefertermin verantworten oder entscheiden, was das Team baut. Genau diese Aufgaben werden in der Praxis ständig in die Rolle hineingezogen, und so wird aus einem Scrum Master ein Projektkoordinator mit anderem Jobtitel. Laut Guide ist die Verantwortlichkeit die Wirksamkeit des Teams, mehr nicht, keine daran angehängte Berichtsfunktion.

Wo die beiden kollidieren und wie gesunde Teams das lösen

Diesen Teil überspringen die meisten Vergleiche, dabei ist er im Alltag der wichtigste. Die beiden Verantwortlichkeiten sind nicht als Gegner angelegt, ziehen aber oft genug in unterschiedliche Richtungen, sodass Reibung normal ist und kein Zeichen dafür, dass etwas kaputt ist.

Das Muster hinter allen fünf Zeilen: Die Aufgabe des Product Owners ist es, für Wert zu streiten und schnell voranzukommen, die Aufgabe des Scrum Masters ist es, die Fähigkeit des Teams zu schützen, diesen Wert nachhaltig zu liefern. Keiner der beiden Instinkte ist für sich genommen falsch. Die Reibung ist das System bei der Arbeit, nicht sein Versagen, solange nicht einer die Verantwortlichkeit des anderen übergeht, nur um die Spannung loszuwerden.

Scrum-Event für Scrum-Event: Wer macht was

Beide Verantwortlichkeiten sind in jedem Event präsent, aber mit unterschiedlicher Haltung. Der eine bringt Inhalt mit, der andere schützt den Rahmen, in dem er stattfindet.

Kann eine Person beides übernehmen?

Manchmal, und es hält meist nicht lange. Die beiden Verantwortlichkeiten ziehen strukturell gegeneinander: Die Aufgabe des Product Owners belohnt ein Ja zum Wert und schnelles Vorankommen, die Aufgabe des Scrum Masters belohnt den Schutz des Teamtempos und Widerspruch, wenn Geschwindigkeit die Qualität gefährdet. Steckt man beide Anreize in einen Kopf, gewinnt fast immer eine Seite automatisch, meist die mit dem lauteren, unmittelbareren Druck (eine Stakeholder-Deadline schlägt in der Regel ein unscheinbares Coaching-Gespräch).

Die Delegationsklausel des Guides macht das für eine kombinierte Rolle schlimmer, nicht besser. Das Delegieren von Aufgaben verringert die Gesamtverantwortung nicht, es bündelt lediglich zwei getrennte Arten von Verantwortlichkeit in einem Kalender. Ein kombinierter Product Owner und Scrum Master erledigt nicht die Hälfte von zwei Jobs, er ist für beide voll verantwortlich, mit den Stunden einer Person.

Davon zu unterscheiden ist eine andere Art der Rollenverdichtung. Large-Scale Scrum (LeSS) setzt bewusst einen einzigen Product Owner über viele Teams ein, die an einem Produkt arbeiten, aber aus dem entgegengesetzten Grund: um zu verhindern, dass sich Prioritäten auf konkurrierende Backlogs zersplittern, nicht um Personal zu sparen. Das ist ein Product Owner, der mehr Teams abdeckt, nicht eine Person, die zwei verschiedene Verantwortlichkeiten abdeckt. Wenn Ihre Organisation über ein einzelnes Team hinaus skaliert, lohnt sich die Lektüre zu LeSS und ähnlichen Skalierungsansätzen, bevor jemand aus der Not eine kombinierte Rolle improvisiert.

Wo es tragfähig ist: in sehr kleinen, konfliktarmen Teams, ausdrücklich als vorübergehende Lösung behandelt und neu bewertet, sobald das Team oder die Stakeholder-Liste wächst. Das Problem ist nicht der Versuch. Es ist, nie zu planen, die Kombination wieder aufzulösen.

Scrum Master und Product Owner vs. Projektmanager und Produktmanager

Weder Scrum Master noch Product Owner ist ein Projektmanager unter anderem Namen, auch wenn beide in der Praxis stillschweigend Teile dieser Aufgabe übernehmen. Und der Product Owner hat bereits einen ausführlichen Vergleich mit dem Produktmanager: Lesen Sie Product Owner vs. Product Manager für die Asymmetrie zwischen Verantwortlichkeit und Jobtitel, die den Großteil dieser Verwechslung antreibt (die Kurzfassung: Der Product Owner wird durch ein einziges Dokument definiert, der Product Manager durch keines).

Der Vergleich des Scrum Masters mit dem Projektmanager ist eine klarere Trennung, weil sich die beiden Aufgaben in dem, was sie verantworten, kaum überschneiden.

Ein vollständigeres Bild davon, wo Projekt- und Programmmanagement von beiden Scrum-Verantwortlichkeiten abweichen, finden Sie in unserem Vergleich Programm- vs. Projektmanagement.

Wen Sie zuerst einstellen sollten oder was Sie werden sollten

Häufige Anti-Patterns

Nichts davon ist eine einmal getroffene und dann vergessene Organisationsentscheidung. Teams verändern ihre Größe, Produkte ihre Phase, und die Reibungspunkte aus der Kollisionstabelle oben tauchen jedes Mal wieder auf, wenn sich etwas verschiebt, sei es ein neuer Stakeholder, ein wachsendes Backlog oder ein Team, das einer kombinierten Rolle entwachsen ist, mit der es aus der Not begonnen hat. Der schnellste Weg zurück zur Klarheit ist dann nicht eine neue Debatte über Titel. Es ist der Satz, auf dem jede Verantwortlichkeit ursprünglich aufbaut: Wer steht für den Wert des Produkts ein, und wer für die Fähigkeit des Teams, ihn zu liefern.

Ob Sie gerade einstellen, ein verschwommenes Team entwirren oder Ihren Karriereweg wählen: Der Satz, auf den Sie immer wieder zurückkommen sollten, ist der, den der Guide tatsächlich geschrieben hat. Eine Person ist für den Wert des Produkts verantwortlich, die andere für die Wirksamkeit des Teams. Alles andere ist Detail.