Scrum Rollen einfach erklärt: Product Owner, Scrum Master und Developer

„Und wer ist bei euch der Projektleiter?" – wenn diese Frage in einem Scrum-Team fällt, weißt du: Die Rollen sind noch nicht angekommen. Dabei ist das Rollenmodell von Scrum bewusst einfach gehalten. Es gibt genau drei Verantwortlichkeiten: Product Owner, Scrum Master und Developer. Nicht mehr, nicht weniger.

In diesem Artikel bekommst du alle drei Rollen einfach erklärt – mit dem, was sie wirklich tun, was sie eben nicht tun, und den Missverständnissen, die mir in der Praxis am häufigsten begegnen. Ich begleite seit Jahren Teams bei der Scrum-Einführung, und fast immer entscheidet die Klarheit über die Rollen darüber, ob Scrum funktioniert oder nur so heißt.

Die drei Scrum Rollen im Überblick

Bevor wir in die Details gehen, die Kurzfassung als Tabelle:

Wichtig: Seit dem Scrum Guide 2020 heißen die Rollen offiziell „Accountabilities" – Verantwortlichkeiten. Das ist mehr als Wortkosmetik. Es betont, dass es nicht um Jobtitel geht, sondern darum, dass bestimmte Dinge im Team verlässlich verantwortet werden.

Der Product Owner: Wert maximieren, nicht Wünsche sammeln

Der Product Owner (PO) ist dafür verantwortlich, dass das Team am Wertvollsten arbeitet – nicht am Lautesten, nicht am Ältesten im Backlog, sondern an dem, was dem Produkt und seinen Nutzer:innen am meisten bringt.

Was der Product Owner konkret tut

• Product Backlog pflegen und ordnen: Der PO entscheidet, was oben steht. Die Reihenfolge ist seine wichtigste Stellschraube.
• Produktziel formulieren: Wohin entwickelt sich das Produkt? Ohne Ziel ist jedes Backlog nur eine Wunschliste.
• Stakeholder managen: Anforderungen einsammeln kann jeder. Der PO verhandelt, priorisiert und sagt auch mal Nein – freundlich, aber klar.
• Verfügbar sein: Developer brauchen schnelle Antworten auf fachliche Fragen. Ein PO, den man nie erreicht, bremst das ganze Team.

Das häufigste Missverständnis

Der PO ist kein „Anforderungs-Briefkasten", der Wünsche von Stakeholdern entgegennimmt und ins Backlog kippt. Genau daran scheitern viele Scrum-Einführungen: Der PO traut sich nicht zu priorisieren, weil er es allen recht machen will. Das Ergebnis ist ein Backlog mit 400 Einträgen, von denen niemand mehr weiß, warum sie drinstehen. Ein guter PO löscht mehr, als er hinzufügt.

Der Scrum Master: Wirksamkeit statt Wohlfühlmanagement

Der Scrum Master ist die am häufigsten missverstandene Rolle. Er ist weder Chef des Teams noch dessen Assistent – er ist dafür verantwortlich, dass Scrum verstanden und wirksam gelebt wird.

Was der Scrum Master konkret tut

• Hindernisse beseitigen: Alles, was das Team bremst – von fehlenden Zugängen bis zu Konflikten mit anderen Abteilungen – landet auf seinem Tisch.
• Das Team coachen: Selbstorganisation entsteht nicht per Ansage. Der Scrum Master hilft dem Team, eigene Entscheidungen zu treffen und dabei besser zu werden.
• Events wirksam machen: Nicht „Meetings organisieren", sondern dafür sorgen, dass Daily, Review und Retrospektive echten Nutzen stiften – und abschaffen, was keinen stiftet.
• Die Organisation weiterentwickeln: Ein Scrum Master, der nur im Team wirkt, nutzt die Hälfte seiner Rolle. Oft liegen die größten Hindernisse außerhalb des Teams.

Das häufigste Missverständnis

„Der Scrum Master lädt zu den Meetings ein und schreibt das Protokoll." Wenn das die Jobbeschreibung ist, braucht es keinen Scrum Master, sondern einen Kalender. Die Rolle ist anspruchsvoll: Sie verlangt Moderationskompetenz, Konfliktfähigkeit und den Mut, auch Führungskräften unbequeme Wahrheiten zu sagen. Ein guter Indikator: Wird es im Team spürbar schlechter, wenn der Scrum Master zwei Wochen im Urlaub ist? Wenn nein, hat er seinen Job gut gemacht – das Team trägt sich selbst.

Die Developer: mehr als Programmierer

„Developer" meint in Scrum alle, die am Increment arbeiten – nicht nur Softwareentwickler:innen. In einem Marketing-Team können das Texter, Designerinnen und Analysten sein. Entscheidend ist: Die Developer verantworten gemeinsam, dass am Ende des Sprints ein nutzbares Ergebnis in vereinbarter Qualität steht.

Was die Developer konkret tun

• Sprint planen: Sie entscheiden selbst, wie viel Arbeit in einen Sprint passt – nicht der PO, nicht das Management.
• Qualität sichern: Die Definition of Done ist ihr Qualitätsversprechen. Sie gilt ohne Ausnahme, auch wenn es eng wird.
• Sich täglich abstimmen: Das Daily gehört den Developern. Es ist ihr Planungsinstrument, kein Statusbericht nach oben.
• Einander verantwortlich halten: „Das war nicht mein Ticket" gibt es in gut funktionierenden Teams nicht. Verantwortet wird gemeinsam.

Das häufigste Missverständnis

Selbstorganisation heißt nicht „jeder macht, was er will". Sie heißt: Das Team entscheidet innerhalb eines klaren Rahmens – Sprintziel, Definition of Done, Produktziel – selbst über den Weg. Dieser Rahmen macht den Unterschied zwischen Selbstorganisation und Chaos.

Warum es keinen Projektleiter gibt

Die klassische Projektleiter-Rolle bündelt drei Dinge in einer Person: fachliche Priorisierung, Prozessverantwortung und Umsetzungssteuerung. Scrum verteilt genau diese drei Dinge bewusst auf drei Schultern:

1. Die fachliche Priorisierung liegt beim Product Owner.
2. Die Prozessverantwortung liegt beim Scrum Master.
3. Die Umsetzungssteuerung liegt bei den Developern selbst.

Das ist kein Zufall, sondern das Kernprinzip: Eingebaute Gewaltenteilung. Wenn eine Person gleichzeitig priorisiert, den Prozess kontrolliert und die Umsetzung steuert, entsteht ein Flaschenhals – und das Team lernt, auf Anweisungen zu warten. Deshalb ist auch die beliebte Doppelrolle „PO und Scrum Master in Personalunion" fast immer eine schlechte Idee: Der PO will Tempo, der Scrum Master schützt die Nachhaltigkeit. Diese produktive Spannung braucht zwei Personen.

Die 5 häufigsten Fehler bei der Rollenverteilung

1. Der Teamleiter wird automatisch Scrum Master. Disziplinarische Macht und Coaching-Rolle vertragen sich schlecht – wer ehrliche Retrospektiven will, sollte das trennen.
2. Der PO sitzt in einer anderen Abteilung und hat „noch andere Projekte". Ein PO mit 10 % Zeitbudget ist kein PO, sondern ein Engpass.
3. Der Scrum Master betreut fünf Teams gleichzeitig. Dann bleibt nur Zeit für Terminorganisation – genau das, was die Rolle nicht sein soll.
4. Stakeholder steuern an dem PO vorbei direkt ins Team. Damit ist die Priorisierung wertlos und der Sprint ständig in Gefahr.
5. Rollen werden vergeben, aber nie erklärt. Wer nie verstanden hat, warum es die Rollen gibt, füllt sie mit alten Gewohnheiten – und nennt den PO dann eben doch Projektleiter.

So bringst du die Rollen ins Team

Rollenklarheit entsteht nicht durch eine Folie im Kickoff, sondern durch Gespräche. Was in meinen Workshops gut funktioniert: Lass das Team selbst zuordnen. Schreibe typische Aufgaben auf Karten – „entscheidet über die Backlog-Reihenfolge", „moderiert die Retrospektive", „schätzt den Aufwand" – und lass das Team diskutieren, zu welcher Rolle sie gehören. Die Diskussionen, die dabei entstehen, sind wertvoller als jede Schulungsfolie, weil Missverständnisse sichtbar werden, bevor sie im Alltag Schaden anrichten.

Genau für solche Formate haben wir die Scrum Cards entwickelt: 40 extra große Karten, die das komplette Scrum Framework greifbar machen – Rollen, Events und Artefakte zum Anfassen, Sortieren und Diskutieren statt zum Durchklicken. Sie sind aus echten Workshop-Situationen entstanden und werden inzwischen von Teams bei DB, VW und Computacenter eingesetzt. Und wenn du neben Scrum auch Check-ins, Delegation und OKRs methodisch begleiten willst, findest du alle fünf Kartensets im Komplett-Set. 🌳 Übrigens: Für jeden Kauf pflanzen wir einen Baum.

Fazit: Drei Rollen, ein Ziel

Scrum verteilt Verantwortung bewusst auf drei Rollen: Der Product Owner verantwortet das Was, der Scrum Master das Wie der Zusammenarbeit, die Developer das Wie der Umsetzung. Keine der drei Rollen ist „Chef" der anderen – sie funktionieren nur zusammen. Wenn du in deinem Team nur eine Sache verbesserst, dann diese: Sprecht einmal explizit darüber, wer was verantwortet. Die meisten Rollenkonflikte entstehen nicht aus bösem Willen, sondern aus stillschweigend unterschiedlichen Erwartungen.