Scrum Rollen – was genau unterscheidet Product Owner und Scrum Master im Alltag?

AnnaWInf

Wir hatten das Thema gerade im Modul Projektmanagement/Prozesse und ich sitze mit meinen Unterlagen da und weiß theoretisch, dass der Product Owner für das „Was“ zuständig ist und der Scrum Master für das „Wie“ im Sinne von Prozessbegleitung. Aber sobald ich mir vorstelle, wie das im echten Projektalltag aussieht, wird es bei mir unscharf.

Konkret hänge ich an Fragen wie: Wer entscheidet eigentlich, wenn das Team mitten im Sprint merkt, dass eine Anforderung aus dem Product Backlog so nicht umsetzbar ist? Greift da der PO ein oder moderiert das der Scrum Master nur? Und wie ist das mit Priorisierungskonflikten im Team – ist das reine PO-Sache oder mischt der Scrum Master da auch inhaltlich mit?

In der Theorie klingt die Trennung sauber, aber ich kann mir schwer vorstellen, wie das im Daily oder Sprint Review tatsächlich abläuft, ohne dass sich die beiden Rollen ständig überschneiden. Hat jemand von euch das schon in einem echten Projekt (egal ob Praktikum, Werkstudentenjob oder im Job selbst) erlebt und kann mir erzählen, wo die Grenze in der Praxis wirklich verläuft?

DanielIT

Hallo Anna, das Thema hatte ich auch erst in der Theorie und später im Werkstudentenjob konkret erlebt. Zu deinem Beispiel mit der nicht umsetzbaren Anforderung: Das ist tatsächlich erstmal eine fachliche Frage, also PO-Territorium. Das Team meldet im Daily oder notfalls sofort, dass die Anforderung technisch nicht wie beschrieben umsetzbar ist, und der PO entscheidet dann, ob die Anforderung angepasst, vertagt oder aus dem Sprint genommen wird. Er kennt ja den fachlichen Kontext und die Prioritäten im Product Backlog am besten.

Die Priorisierung selbst ist bei uns immer strikt PO-Sache gewesen. Das Team darf natürlich Einwände bringen, etwa technische Abhängigkeiten aufzeigen, aber die finale Entscheidung, was oben im Backlog steht, liegt beim PO. Der Scrum Master mischt sich da inhaltlich nicht ein, sondern sorgt eher dafür, dass der Prozess dahinter funktioniert, also zum Beispiel dass Refinement-Termine stattfinden, in denen genau solche Konflikte besprochen werden können, bevor sie im Sprint eskalieren.

Mein Merksatz dazu: Der PO verantwortet das Ergebnis des Backlogs, der Scrum Master verantwortet, dass der Weg dorthin reibungslos läuft. Überschneidungen gibt es trotzdem, gerade wenn der Scrum Master merkt, dass Priorisierungskonflikte im Team an mangelnder Kommunikation liegen. Dann moderiert er, entscheidet aber nicht inhaltlich.

Tobi89

Daniels Merksatz trifft's gut, ich ergänz nochmal einen Punkt, der mir in der Praxis oft Kopfzerbrechen gemacht hat: die Abgrenzung Scrum Master vs. klassischer Teamlead. Das ist nämlich ein Denkfehler, den viele am Anfang machen, gerade wenn man aus klassischen Projektstrukturen kommt.

Ein Teamlead hat meistens disziplinarische oder zumindest fachlich-weisungsbefugte Verantwortung: er sagt, wer was macht, bewertet Leistung, greift bei Konflikten auch inhaltlich durch. Der Scrum Master hat das explizit nicht. Er ist kein Chef des Teams, sondern Prozess-Hüter und Moderator ohne Weisungsbefugnis. Wenn im Daily Chaos herrscht, sagt er nicht „macht das jetzt so", sondern fragt eher, woran es hakt und hilft, dass das Team selbst eine Lösung findet. Self-organizing Team ist da das Stichwort.

Typischer Fehler in der Praxis: Firmen besetzen die Scrum-Master-Rolle mit dem ehemaligen Teamlead und der fällt dann in alte Muster zurück, trifft inhaltliche Entscheidungen oder mischt sich in Priorisierung ein. Das konterkariert eigentlich das ganze Scrum-Konzept, weil die Verantwortung dann nicht mehr sauber getrennt ist.

Merksatz von mir: Scrum Master optimiert den Prozess, Teamlead optimiert (oft) Menschen und Ergebnisse direktiv. Deckt sich nicht automatisch.

AnnaWInf

Danke euch beiden, das bringt für mich echt Struktur rein, vor allem der Punkt mit dem Teamlead-Denkfehler, Tobi. Ich hatte dazu letztes Semester im Praxisprojekt (Uni-intern, aber mit echtem Kunden) einen Fall, der genau in diese Richtung ging.

Bei uns gab es im Sprint eine Situation, wo zwei Entwickler sich nicht einig waren, wie eine Story technisch umzusetzen ist, und das hat sich dann als vermeintlicher Prioritätskonflikt im Daily entladen. Unser Scrum Master hat da bewusst nicht gesagt „macht's so", sondern hat vorgeschlagen, das Thema aus dem Daily rauszunehmen und in ein separates kurzes technisches Spike-Meeting zu packen. Der PO war dabei nur als Zuhörer anwesend, weil die fachliche Anforderung unstrittig war, es ging rein um den Lösungsweg.

Das fand ich im Nachhinein ein gutes Beispiel für die Grenze: Der Scrum Master hat erkannt, dass das eigentliche Problem ein Prozess-/Kommunikationsproblem war (zwei Lösungswege im Daily diskutieren funktioniert einfach nicht), und hat den Rahmen geschaffen, damit das Team selbst entscheidet. Hätte es aber um die Frage gehen, ob die Story überhaupt noch in diesem Sprint Sinn macht, wäre sofort der PO gefragt gewesen.

Mein Fazit aus der Erfahrung: Je klarer vorher getrennt ist, wer worüber entscheidet, desto seltener eskaliert sowas überhaupt erst im Daily.

Scrum Rollen – was genau unterscheidet Product Owner und Scrum Master im Alltag?

Jetzt mitmachen!

Letzte Beiträge

Vendor Lock-in bei Cloud-Diensten – wie vermeide ich die Abhängigkeit? 2

Prozessmodellierung mit BPMN – wie unterscheide ich Gateway-Typen sauber? 2

Testdatenbank vs. Produktivsystem – wie trenne ich das sauber im Projekt? 2

Lastenheft und Pflichtenheft – wer schreibt eigentlich was? 2

Microservices oder Monolith – was eignet sich besser für mein Studienprojekt? 3

DSGVO im Studienprojekt – was muss ich bei selbst erhobenen Umfragedaten beachten? 2

ER-Diagramm vs. UML-Klassendiagramm – wann nehme ich was? 2

Cloud Computing: SaaS, PaaS, IaaS – wie unterscheide ich die Modelle in der Klausur? 2

Clean Code Prinzipien – lohnt sich der Aufwand im Studienprojekt wirklich? 2

Versionskontrolle vs. Backup – reicht Git allein als Datensicherung für mein Projekt? 2

Vendor Lock-in bei Cloud-Diensten – wie vermeide ich die Abhängigkeit?

Prozessmodellierung mit BPMN – wie unterscheide ich Gateway-Typen sauber?

Testdatenbank vs. Produktivsystem – wie trenne ich das sauber im Projekt?

Lastenheft und Pflichtenheft – wer schreibt eigentlich was?

Microservices oder Monolith – was eignet sich besser für mein Studienprojekt?

Über Study-Board.de