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

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.

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.