RollenRollenporträt
Product Owner: Aufgaben und Verantwortung im Scrum Team
Inhalt dieses Artikels
Der Product Owner ist im Scrum Team dafür verantwortlich, den Wert des Produkts zu maximieren, und führt dafür den Product Backlog. Er entscheidet, was das Team als Nächstes umsetzt und in welcher Reihenfolge, aber nicht, wie es das tut.
Daraus folgt der Kern der Rolle: Ein Product Owner muss entscheiden dürfen. Eine Person, die Wünsche sammelt und weiterreicht, ohne die Reihenfolge festlegen zu können, füllt die Rolle nicht aus.
Wofür der Product Owner verantwortlich ist
Laut Scrum Guide 2020 ist der Product Owner dafür verantwortlich, den Wert des Produkts zu maximieren, das aus der Arbeit des Scrum Teams entsteht. Wie er das tut, kann sich laut Guide zwischen Organisationen, Teams und Personen stark unterscheiden. Dazu kommt die Verantwortung für ein wirksames Management des Product Backlogs.
Der Product Owner ist eine Person, kein Gremium. Er kann die Bedürfnisse vieler Stakeholder im Product Backlog vertreten. Wer den Backlog ändern will, muss den Product Owner überzeugen, statt am Product Owner vorbei Aufgaben ins Team zu geben.
Damit das funktioniert, verlangt der Scrum Guide etwas von der Organisation: Sie muss die Entscheidungen des Product Owners respektieren. Sichtbar werden diese Entscheidungen im Inhalt und in der Reihenfolge des Product Backlogs und im Inkrement, das im Sprint Review gezeigt wird.
Genauso wichtig ist, was der Product Owner nicht verantwortet. Wie viel in einen Sprint passt, wählen die Developers aus. Wie sie einen Eintrag umsetzen, entscheiden allein sie. Und wann ein Eintrag fertig ist, legt die Definition of Done fest, nicht die Ungeduld der Stakeholder.
Die vier Aufgaben des Product Owners
Der Scrum Guide zählt vier Aufgaben auf, aus denen das Management des Product Backlogs besteht. Der Product Owner kann sie selbst erledigen oder an andere übertragen, bleibt aber für das Ergebnis verantwortlich.
Das Produktziel entwickeln und vermitteln
Das Produktziel beschreibt einen künftigen Zustand des Produkts, auf den das Team hinarbeitet, etwa: „Neukundinnen und Neukunden können ihren Vertrag vollständig online abschließen.“ Der Product Owner entwickelt dieses Ziel und vermittelt es so, dass Team und Stakeholder es erklären können, ohne nachzulesen.
Das Team verfolgt immer nur ein Produktziel und erfüllt oder verwirft es, bevor es das nächste angeht. Ein Product Owner, der drei Ziele gleichzeitig ausruft, hat in Wahrheit keines festgelegt.
Ein brauchbares Produktziel beschreibt, was für die Menschen besser wird, die das Produkt nutzen. Woran das Team den Fortschritt dorthin misst, legt der Product Owner im Gespräch mit den Developers fest. Eine Kennzahl allein ist kein Produktziel, sie zeigt nur, ob es näher rückt.
Einträge im Product Backlog formulieren
Jeder Eintrag im Product Backlog beschreibt etwas, das das Produkt verbessert. Der Product Owner formuliert die Einträge und erklärt sie, sodass die Developers verstehen, welches Problem dahintersteht und woran sie erkennen, dass es gelöst ist.
Formulieren heißt nicht vorschreiben. Ein guter Eintrag beschreibt, was erreicht werden soll, nicht, welche Felder eine Maske bekommt. Die Details klären Product Owner und Developers gemeinsam im Refinement; die Größe der Einträge schätzen laut Scrum Guide die Developers.
Den Product Backlog ordnen
Der Product Owner legt die Reihenfolge der Einträge fest. Was oben steht, kommt als Nächstes ins Sprint Planning; was unten steht, ist noch grob und darf es sein. Die Reihenfolge ist die sichtbarste Entscheidung der Rolle, und über sie wird mit Stakeholdern verhandelt.
Der Scrum Guide spricht von einem geordneten Backlog, nicht von einem priorisierten. Der Unterschied ist praktisch: Zwei Einträge können nicht beide auf Platz eins stehen. Wer alles als „hohe Priorität“ markiert, hat die Reihenfolge nicht festgelegt, sondern dem Team überlassen.
Den Product Backlog transparent halten
Der Product Backlog muss für alle Beteiligten sichtbar und verständlich sein. Transparenz ist laut Scrum Guide die Voraussetzung dafür, dass Team und Stakeholder Entscheidungen überprüfen können. Ein Backlog in einer Datei, die nur der Product Owner öffnet, erfüllt das nicht.
Praktisch heißt das: Jede und jeder im Team kann sagen, was als Nächstes kommt und warum. Stakeholder sehen, wo ihr Wunsch steht und weshalb. Diese Offenheit erspart Einzelgespräche, weil die Antwort auf „Wann kommt mein Thema?“ im Backlog steht.
Eine typische Woche als Product Owner
Die Woche eines Product Owners teilt sich zwischen dem Team und den Menschen außerhalb des Teams. Als Faustregel für die erste Woche eines Zwei-Wochen-Sprints:
Montag: Sprint Planning. Der Product Owner schlägt vor, wie der Sprint den Wert des Produkts steigern kann, und formuliert mit dem Team das Sprint-Ziel. Welche Einträge in den Sprint passen, wählen die Developers im Gespräch mit ihm aus.
Dienstag und Mittwoch: Gespräche außerhalb des Teams. Stakeholder, Vertrieb, Support, Kundinnen und Kunden. Hier entstehen neue Einträge und die Gründe für die Reihenfolge. Wer solche Runden mit mehreren Beteiligten leitet, kann Workshops mit Stakeholdern moderieren, statt jede Anfrage einzeln zu verhandeln.
Donnerstag: Refinement mit den Developers. Große Einträge werden zerlegt, unklare präzisiert. Der Product Owner beantwortet Fachfragen, die Developers schätzen die Größe.
Freitag: Daten und Rückmeldungen. Wie wird das letzte Inkrement genutzt? Was berichtet der Support? Daraus entsteht die Reihenfolge für die nächste Woche.
In der zweiten Woche steht das Sprint Review an. Dort prüft der Product Owner mit den Stakeholdern, was entstanden ist, und passt den Backlog an. Faustregel: Mindestens die Hälfte der Woche gehört den Gesprächen außerhalb des Teams. Ein Product Owner, der nur im Team sitzt, verwaltet Tickets, statt Wert zu finden.
Product Owner, Scrum Master, Projektleitung: die Abgrenzung
Der Product Owner ist die einzige Verantwortlichkeit im Scrum Team, die über Inhalt und Reihenfolge des Product Backlogs entscheidet. Die Tabelle zeigt die Grenzen zu den benachbarten Rollen:
| Rolle | entscheidet über | verantwortet | Weisungsbefugnis |
|---|---|---|---|
| Product Owner | Produktziel und Reihenfolge im Product Backlog | Wert des Produkts | nein |
| Scrum Master | nichts am Produkt; achtet auf Scrum und Zusammenarbeit | Wirksamkeit des Teams, Einführung von Scrum | nein |
| Developers | wie ein Eintrag umgesetzt wird | nutzbares Inkrement in jedem Sprint | nein |
| Projektleitung | Plan, Termine, Ressourcen eines Vorhabens | Termin, Umfang, Budget | teilweise |
| Teamleitung | Personal und Organisation des Teams | Ergebnisse und Menschen | ja |
Die Grenze zum Scrum Master ist bewusst gezogen: Der Product Owner treibt den Wert, der Scrum Master schützt die Arbeitsweise. Zur Projektleitung fehlt dem Product Owner die Verantwortung für einen festen Endtermin; ein Produkt hat kein Ende, ein Projekt schon.
Ein Product Manager ist eine Stelle, die sich je nach Unternehmen mit dem Product Owner überschneidet, aber über Markt und Strategie hinausgeht. Außerhalb von Scrum gibt es die Rolle nicht: Kanban schreibt keine Rollen vor, und ein Agile Coach entscheidet nichts über das Produkt. Den Überblick über alle agilen Rollen findest du auf der Rollenseite; wie sich Product Owner, Scrum Master und Developers die Arbeit teilen, erklärt der Artikel über die Scrum-Rollen.
Wege in die Rolle
Der erste Weg führt aus dem Fachbereich. Wer Kundinnen, Kunden und Abläufe kennt, bringt das Wissen mit, das für gute Entscheidungen über die Reihenfolge nötig ist. Zu lernen bleibt das Handwerk: Einträge so formulieren, dass Developers damit arbeiten können, und Nein sagen, ohne Stakeholder zu verlieren.
Der zweite Weg führt aus dem Produktmanagement oder der Projektleitung. Wer von dort kommt, kennt Stakeholder und Planung, muss aber zwei Dinge ablegen: feste Endtermine als Maßstab und die Gewohnheit, dem Team das Wie vorzugeben.
Drei Dinge braucht die Rolle mehr als jede Methode: Entscheidungsfreude, weil jede Reihenfolge jemanden enttäuscht. Wissen über die Menschen, die das Produkt nutzen, weil nur daraus Gründe für die Reihenfolge entstehen. Und die Fähigkeit, ein Nein so zu begründen, dass Stakeholder es nachvollziehen können, auch wenn sie es nicht mögen.
Zertifikate für Product Owner bieten unter anderem Scrum.org und die Scrum Alliance an. Vorgeschrieben ist keines. Wichtiger als jedes Zertifikat ist die Entscheidungsbefugnis: Bevor du die Rolle übernimmst, kläre, ob du die Reihenfolge im Backlog wirklich festlegen darfst.
Was an der Rolle schwierig ist
Proxy Product Owner ohne Entscheidungsbefugnis. Die Rolle ist besetzt, aber jede wichtige Frage muss jemand anderes entscheiden. Das Team wartet auf Antworten, und der Product Owner wird zum Boten. Der Scrum Guide verlangt das Gegenteil: Die Organisation muss seine Entscheidungen respektieren.
Product Owner als Anforderungsschreiber. Wer nur Tickets formuliert, die andere bestellt haben, verwaltet den Backlog, statt ihn zu führen. Der Wert entsteht in der Reihenfolge und im Nein, nicht in der Menge der Einträge.
Ein Gremium statt einer Person. Wenn mehrere Fachbereiche gemeinsam über die Reihenfolge abstimmen, gewinnt der lauteste Bereich oder niemand. Der Scrum Guide schließt das ausdrücklich aus: eine Person, kein Gremium.
Zu wenig Zeit für die Rolle. Wird Product Owner als Zusatzaufgabe neben einer Leitungsstelle vergeben, fehlt die Zeit für Refinement und Gespräche, und das Team wartet auf Antworten. Faustregel: Ein Product Owner für ein Team braucht mindestens die Hälfte seiner Arbeitszeit für die Rolle.
Fragen und Antworten
Was macht ein Product Owner?
Ein Product Owner entscheidet, was das Scrum Team als Nächstes umsetzt, damit das Produkt möglichst viel Wert schafft. Dafür entwickelt er das Produktziel, formuliert und ordnet die Einträge im Product Backlog und spricht mit Stakeholdern, Kundinnen und Kunden. Im Sprint Planning schlägt er vor, wie der Sprint den Wert des Produkts steigern kann, im Sprint Review prüft er mit den Stakeholdern das Ergebnis.
Ist der Product Owner Vorgesetzter des Teams?
Nein. Der Product Owner entscheidet über das Was und die Reihenfolge, nicht über das Wie und nicht über die Menschen. Laut Scrum Guide gibt es im Scrum Team keine Hierarchie, und wie die Developers einen Eintrag umsetzen, entscheiden allein sie. Personalverantwortung gehört nicht zur Rolle. Wo eine Teamleitung zugleich Product Owner ist, vermischen sich Prioritäten und Beurteilung, und das Team widerspricht seltener.
Kann der Product Owner zugleich Scrum Master sein?
Der Scrum Guide verbietet es nicht ausdrücklich, er beschreibt beide aber als getrennte Verantwortlichkeiten. Davon ist abzuraten: Der Product Owner drängt auf mehr Wert im Sprint, der Scrum Master schützt die Arbeitsweise des Teams, etwa die Zeitbox oder die Definition of Done. In einer Person verliert leicht die zweite Aufgabe, weil der Druck auf das Produkt sichtbarer ist.
Gibt es mehrere Product Owner für ein Produkt?
Nein. Laut Scrum Guide ist der Product Owner eine Person, kein Gremium. Arbeiten mehrere Scrum Teams am selben Produkt, teilen sie sich ein Produktziel, einen Product Backlog und einen Product Owner. Der Product Owner kann Arbeit an andere delegieren, etwa das Formulieren von Einträgen, bleibt aber für das Ergebnis verantwortlich.
Braucht ein Product Owner technisches Wissen?
So viel, dass er mit den Developers über Aufwand und Risiko sprechen kann, aber nicht so viel, dass er ihnen die Umsetzung vorgibt. Wichtiger ist Wissen über die Menschen, die das Produkt nutzen, und über das Geschäft dahinter. Ein Product Owner, der Entscheidungen über die Technik trifft, nimmt den Developers die Verantwortung, die der Scrum Guide ihnen gibt.
Was ist ein Proxy Product Owner?
Ein Proxy Product Owner ist eine Person, die die Rolle ausfüllt, aber nicht entscheiden darf. Die eigentlichen Entscheidungen trifft jemand anderes, etwa eine Fachbereichsleitung, die keine Zeit für das Team hat. Der Begriff steht nicht im Scrum Guide. Das Problem: Jede Prioritätenfrage braucht eine Rückfrage, und das Team wartet. Der Guide verlangt, dass die Organisation die Entscheidungen des Product Owners respektiert.
Quellen
- Scrum Guide 2020, Abschnitt Product Owner (abgerufen am 3. Oktober 2026)
- Der Scrum Guide 2020, deutsche Übersetzung (PDF) (abgerufen am 3. Oktober 2026)