Scrum-Rollen: Team bespricht Aufgaben

Die 3 Scrum-Rollen: Verantwortung im Team verteilen

Product Owner, Scrum Master, Entwickler*innen – die drei Scrum-Rollen sind schnell benannt. Innerhalb des Scrum-Frameworks arbeitet das agile Team mit verteilter Verantwortung an einem gemeinsamen Ziel: Mehrwert für seine Kunden zu schaffen. Doch was unterscheidet den Scrum Master vom Product Owner? Welche Aufgaben liegen beim Entwickler-Team? Und was genau ist mit „verteilter Verantwortung“ gemeint? Antworten auf diese Fragen liefert unser Artikel.

E-Book
Die 3 Scrum-Rollen: Verantwortung im Team verteilen
Später lesen? Den vollständigen Leitfaden als E-Book herunterladen.
Jetzt herunterladen

Kurz erklärt: die 3 Scrum-Rollen

Ein Scrum-Team setzt sich laut Scrum-Guide aus drei Rollen zusammen: Product Owner, Entwickler*innen und Scrum Master. Innerhalb des Teams existieren keine Hierarchien, alle Mitglieder agieren auf Augenhöhe. Was sie verbindet: ein gemeinsames Produkt-Ziel. Was sie unterscheidet: ihre Verantwortung und Aufgaben auf dem Weg zu diesem Ziel.

Das crossfunktionale Team umfasst alle Kompetenzen und Fähigkeiten, die für die Entwicklung ihres Produkts von Ende-zu-Ende erforderlich sind. Um alle damit verbundenen Aufgaben autonom und selbstorganisiert erledigen zu können, verteilt das Team die Verantwortung auf unterschiedliche Scrum-Rollen.

  • Der Product Owner vertritt dabei die Interessen der Kund*innen und hat eine klare Vision vom Produkt. Er priorisiert die Aufgaben, die im Team erledigt werden und ist ergebnisverantwortlich für die kontinuierliche Verbesserung und Wertmaximierung des Produkts.
  • Während der Product Owner sich darum kümmert, „was getan werden muss“, bestimmen die Entwickler*innen im Team „wie es getan wird“: Die operativen Fachexpert*innen entscheiden, welche Aufgaben sie erledigen, um das Produkt bzw. Produktbestandteile zu erstellen.
  • Zum Team gehört zudem ein Scrum Master. Als methodischer Experte coacht er oder sie die Kolleg*innen und achtet auf die Einhaltung des Scrum-Frameworks. Der Scrum Master hält Störungen vom Team weg und räumt Hindernisse aus, damit die Entwickler*innen ungestört arbeiten können.

Der Product Owner sorgt dafür, dass wir die richtigen Dinge tun. Das Team sorgt dafür, dass es richtig gemacht wird. Der Scrum Master sorgt dafür, dass es die richtigen Personen tun.

Felix Lagemann
Agile Coach von Me & Company
Scrum-Rollen: Die verteilte Führung im Team
Die verteilte Verantwortung der Scrum-Rollen
Die verteilte Verantwortung der Scrum-Rollen

Scrum: eine kompakte Einführung

Scrum ist als agiles Framework in der Softwareentwicklung entstanden. Heutzutage wird es auch in vielen anderen Bereichen eingesetzt und eignet sich vor allem in der fortlaufenden Produktentwicklung und bei Projekten mit längerer Dauer. Im Gegensatz zum klassischen Projektmanagement arbeitet Scrum in kurzen Planungshorizonten und Arbeitszyklen, den sogenannten Sprints. Ein Sprint dauert in der Regel zwei bis drei Wochen, maximal jedoch einen Monat. Am Ende jedes Sprints liefert das Scrum-Team ein Produktbestandteil (Inkrement) aus, der bereits einen Nutzen für den Kunden bietet.

Komplexe Projekte oder Produkte können so mit Scrum in kleine Schritte aufgeteilt werden. Dieser „inkrementelle Ansatz“ bietet einige Vorteile:

  • schnelles sichtbares Ergebnis für Kund*innen
  • Team kann flexibel auf Veränderungen und neue Anforderungen im Projektzyklus reagieren
  • Framework hilft dem Team, sich auf den Kundenmehrwert der geschaffenen Arbeitsergebnisse zu fokussieren
  • Feedback von Kund*innen und anderen Stakeholdern kann während des Projektzyklus aufgenommen und verarbeitet werden

Die 4 Scrum-Meetings

Scrum ist ein Vorgehensmodell, das einen Rahmen zur Organisation der täglichen Zusammenarbeit setzt. Darin kann das Team Methoden einsetzen oder nutzen und Prozesse abbilden. Es entwickelt eine Lösung. Wie es seine Arbeit erledigt, entscheidet das Team eigenständig. Es führt sich selbst, ohne auf Führungskräfte im klassischen Sinn zurückzugreifen.

Das Scrum-Framework gibt dabei die grundlegende Struktur für Meetings, Artefakte und Zuständigkeiten vor. So ist ein Sprint üblicherweise in vier Meetings organisiert:

  • Sprint Planning: In dem Planungstreffen legt das Team fest, welche Aufgaben und Arbeiten innerhalb des Sprints erledigt werden.
  • Daily Standup: Im täglichen Meeting bespricht das Team die aktuellen Aufgaben des Tages. Auch Probleme oder Barrieren, die die Arbeit behindern, sind Thema im Daily.
  • Sprint Review: In der Review präsentiert das Scrum-Team die Sprint-Ergebnisse und holt Feedback von Stakeholdern und Kund*innen ein.
  • Sprint Retrospektive: Die Retrospektive findet am Ende des Sprints statt und hilft dem Team, die interne Zusammenarbeit zu verbessern. Im Rückblick reflektiert das Team, was gut funktioniert hat, was weniger gut lief und was verbessert werden kann.
Die agilen Meetings im Überblick
Die Scrum-Meetings im Überblick: Die Zeiten basieren auf einer Sprintlänge von zwei Wochen (10 Arbeitstagen). Dauert der Sprint länger, verlängert sich entsprechend auch die Dauer der einzelnen Meetings (Ausnahme: das Daily Standup dauert immer 15 Minuten).
Die Scrum-Meetings im Überblick: Die Zeiten basieren auf einer Sprintlänge von zwei Wochen (10 Arbeitstagen). Dauert der Sprint länger, verlängert sich entsprechend auch die Dauer der einzelnen Meetings (Ausnahme: das Daily Standup dauert immer 15 Minuten).

Scrum-Rollen und Verantwortlichkeiten im Team

Innerhalb des Scrum-Frameworks organisiert sich das Team selbst. Es verteilt die Zuständigkeiten und Verantwortung für die einzelnen Tätigkeiten auf die drei Scrum-Rollen Product Owner, Entwickler*innen und Scrum Master. Im Team existiert deshalb auch keine Hierarchie. Nach dem Scrum-Guide ist das Scrum-Team eine „geschlossene Einheit von Fachleuten“.

Scrum Teams sind interdisziplinär, d.h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint Wert zu schaffen. Sie managen sich außerdem selbst, d.h. sie entscheiden intern, wer was wann und wie macht.

Scrum Guide

Die Scrum-Rollen stellen keine Positionsbezeichnungen dar: Je nach Produkt, Service oder Lösung, die entwickelt wird, ist das Team mit unterschiedlicher Expertise besetzt. Bei der Entwicklung einer Banking-App sind andere Kompetenzen gefragt als bei der Konzeption eines Online-Magazins. So kann das Entwickler-Team beispielsweise aus Backend- und Frontend-Developer*innen und UX-Designer*innen oder aus Grafiker*innen und Texter*innen bestehen. Oder aus allen vier dieser Kompetenzen.

Product Owner: Hüter des Backlogs mit Produktvision

Der Product Owner (PO) hat die Produktvision im Blick: Er gibt die Zielrichtung vor und ist ergebnisverantwortlich für die „Maximierung des Wertes des Produkts“ (Scrum-Guide). Als Interessensvertreter der Kund*innen und anderer Stakeholder des Unternehmens sammelt er die Anforderungen an das Produkt im Product Backlog und verwandelt sie in zu bearbeitende Aufgaben (Backlog-Items). Diese Backlog-Items sind so konzipiert, dass sie innerhalb eines Sprints abgeschlossen werden können.

Ausbildung zum Agile Coach

Treiben Sie den Kulturwandel in Ihrem Unternehmen voran. In unserer berufsbegleitenden Ausbildung erhalten Sie alle Werkzeuge, die es braucht, um die Rolle des Agile Coach einzunehmen.

Erfahren Sie mehr zur Ausbildung
Agile Coaches sorgen für mehr Kommunikation zwischen Interessensgruppen

Der Product Owner priorisiert die Aufgaben und legt fest, in welcher Reihenfolge die Backlog-Einträge bearbeitet werden. Für eine erfolgreiche Zusammenarbeit, muss das Team den Entscheidungen zustimmen bzw. diese akzeptieren. In der Praxis nimmt der PO die Priorisierung in der Regel auch gemeinsam oder in Rücksprache mit dem Team vor. Er sorgt dafür, dass der Product Backlog transparent und für alle einsehbar ist. Wer die Einträge im Backlog oder die Reihenfolge ihrer Bearbeitung ändern möchte, muss den PO von dieser Notwendigkeit überzeugen. Die letzte Entscheidung liegt aber immer beim Product Owner. Er ist auch der Einzige, der die Autorität hat, einen Sprint vorzeitig abzubrechen.

Zusammenfassend trägt der Product Owner die Verantwortung für drei Aufgaben:

  • Management des Product Backlogs: Der PO formuliert das Produktziel und erstellt die Backlog-Einträge. Zudem priorisiert er die Reihenfolge der Einträge und stellt sicher, dass das Backlog transparent, sicher und verständlich ist. Er kann Teile dieser Aufgaben (z. B. Erstellung der Backlog-Einträge) an das Team delegieren. Dennoch bleibt er ergebnisverantwortlich für den Mehrwert des zu entwickelnden Produkts.
  • Stakeholder-Management: Der Product Owner bezieht die Interessen aller Stakeholder des Produkts (Nutzer*innen, Kund*innen, Unternehmensvertreter*innen) ein. Er muss dementsprechend im regelmäßigen Austausch mit diesen Gruppen sein und ihre Anforderungen aufnehmen. Nur so kann er sicherstellen, dass die Backlog-Einträge sinnvoll strukturiert sind und die Entwickler*innen einen Mehrwert schaffen können.
  • Release-Management: Der PO muss immer im Blick haben, wann die die entwickelten Lösungen zum Nutzer kommen. Es gibt im Sprintzyklus keine festen Releasedaten. Das Team kann jederzeit ausliefern, ideal sind mehrere Releases während des Sprints. Aus diesem Grund muss der Product Owner immer wissen, wann die einzelnen Inkremente veröffentlicht werden können.

Entwickler*innen: Team aus Machern schafft Mehrwert

Die Entwickler*innen sind die operativen Fachexpert*innen im Team. Sie sind es, die das Produkt erstellen bzw. in jedem Sprint ein Produkt-Inkrement liefern. Das bedeutet aber nicht, dass alle Entwickler*innen „gleich“ sind oder die gleichen Aufgaben haben. Im Gegenteil: In der Regel ist dieses „Macher-Team“ eine crossfunktionale Gruppe von Fachkräften mit unterschiedlichen Kompetenzen, die gemeinsam an der Erstellung des Produkts arbeiten. Sie organisieren sich eigenständig und entscheiden, welche Arbeiten sie ausführen müssen, um das jeweilige Sprintziel zu erreichen.

Deswegen ist der Begriff „Entwickler*innen“ eventuell auch irreführend. Scrum stammt aus der Softwareentwicklung. In der ursprünglichen Anwendung bestand dieser Teil des Scrum-Teams in der Regel tatsächlich aus Software-Entwickler*innen. Da das Framework aber mittlerweile auch in anderen Bereichen eingesetzt wird, können die „Entwickler*innen“ auch Business-Analyst*innen, Marketing-Manager*innen oder HR-Business Partner*innen sein – eben die Personen, die eine Lösung für eine Nutzergruppe (unternehmensintern oder extern) erarbeiten. Der Einfachheit halber haben wir hier analog zum Scrum Guide den Begriff Entwickler*innen gewählt – auch wenn damit viele unterschiedliche Kompetenzen unter einer Bezeichnung zusammengefasst werden.

Zentrale Aufgabe des Entwicklungs-Teams ist es, in jedem Sprint einen Wert für die Kund*innen in Form eines Inkrements zu liefern. Dabei sind sie verantwortlich dafür,

  • einen Plan für den jeweiligen Sprint zu erstellen,
  • die Qualität zu sichern durch das Einhalten einer gemeinsam definierten Definition of Done und der Erfüllung der Requirements, die in den einzelnen Backlog-Items definiert wurden,
  • täglich den Plan zur Erreichung des Sprint‐Ziels anzupassen und
  • sich gegenseitig als Expert*innen zu beraten.
Managen Sie Ihre Projekte mit Scrum

Lernen Sie in unseren “Agile Atoms”, wie Sie das Scrum-Framework auch in Ihrem Unternehmen implementieren. Passen Sie unser modulares Trainingsprogramm individuell auf Ihre Bedürfnisse an.

Zu den Agile Atoms
Collage mit Eindrücken, wie Personen Räumlichkeiten und Büromöbel kreativ zu ihrem Vorteil nutzen

Scrum Master: Scrumexperte und Teamcoach

Der Scrum Master ist wie der Product Owner Servant Leader des Scrum-Teams. Das bedeutet aber nicht, dass er oder sie im Team eine herausgehobene Führungsrolle einnimmt. Er ist kein Projektleiter, der Aufgaben vorgibt und die Arbeit des Teams plant, sondern vielmehr ein Coach: Als methodischer Experte ist der Scrum Master verantwortlich dafür, dass die Scrum-Regeln und -Prinzipien im Team eingehalten werden. Er vermittelt die fünf Scrum-Werte (Mut, Fokus, Enagement, Respekt und Offenheit) und unterstützt seine Kolleg*innen darin, das Scrum-Framework effektiv umzusetzen.

Der Scrum Master ist ergebnisverantwortlich für die Einführung von Scrum, wie es im Scrum Guide definiert ist. Er tut dies, indem er allen dabei hilft, die Scrum‐Theorie und ‐Praxis zu verstehen, sowohl innerhalb des Scrum Teams als auch in der Organisation.

Scrum Guide

Der Scrum Master schafft die bestmöglichen Rahmenbedingungen, damit das Team kundenzentriert und selbstorganisiert arbeiten kann. Er sorgt für einen störungsfreien Sprint und unterstützt die Entwickler*innen dabei, Hindernisse (Impediments) in der täglichen Arbeit zu beseitigen. Als Teammitglied verantwortet der Scrum Master die Zusammenarbeit und unterstützt Entwickler*innen und Product Owner bei der gemeinsamen Zielerreichung. Als Moderator stellt er zudem sicher, dass die vier Scrum-Events (Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospektive) stattfinden und produktiv sind.

Der Scrum-Guide unterstreicht die „dienende Funktion“ des Scrum Masters: So unterstützt er

  • den Product Owner bei der Definition des Produkt-Ziels, beim Management des Product Backlogs und der Zusammenarbeit mit den Stakeholdern,
  • die Entwickler*innen in der Selbstorganisation und bei der Fokussierung auf die Schaffung hochwertiger Inkremente sowie
  • das Unternehmen bei der Einführung von Scrum.

Bonus-Rolle: Stakeholder

Unter den Stakeholdern versteht man alle Personen, die nicht zum Scrum-Team gehören, aber dennoch Interesse am Erfolg des Produkts haben oder notwendiges Wissen mitbringen. Das können Kund*innen, Auftraggeber*innen oder andere Unternehmensvertreter*innen sein. Stakeholder geben Anforderungen an das Produkt oder Projekt vor, an der operativen Umsetzung beteiligen sie sich nicht. Sie gehören also nicht zu den klassischen Scrum-Rollen.

Dennoch nehmen sie am Scrum-Prozess teil. So stehen sie im Austausch mit dem Product Owner und/oder den Entwickler*innen, um Anforderungen an das Produkt einzureichen oder zu ändern. Darüber lädt das Scrum-Team die Stakeholder zur Sprint Review ein und präsentiert ihnen die Ergebnisse des zurückgelegten Sprint-Zyklus. Hier können sie dann Feedback und Verbesserungsvorschläge geben.

Praxis-Beispiel: die Scrum-Rollen außerhalb der Softwareentwicklung

Viele Scrum-Beispiele stammen aus der Softwareentwicklung. Wie schon oben geschrieben, lässt sich das Framework aber auch gut in anderen Bereichen umsetzen. Im Folgenden skizzieren wir die Scrum-Rollen an einem (fiktiven) Beispiel, das nicht aus der Softwareentwicklung stammt: Die Redaktion einer monatlich erscheinenden Zeitschrift hat beschlossen, ihr Magazin künftig mit Scrum zu entwickeln. Die frühere Redaktionsleiterin Claudia ist nun Product Owner. Sie pflegt und verwaltet den Redaktionsplan in Form eines Backlogs und priorisiert die Themen, die pro Ausgabe abgedruckt werden. Das Entwicklungsteam besteht u. a. aus Redakteur*innen, Grafiker*innen und Anzeigenverkäufer*innen, die die Zeitschrift mit Inhalten füllen. Ein neu eingestellter Scrum Master unterstützt das Team in den Regel-Meetings und sorgt dafür, dass das Team ungestört an seinen Themen arbeiten kann.

Ihr Produkt ist die final entwickelte Zeitschrift – vor Drucklegung und Versand. Diese Aufgaben werden in anderen Teams erledigt. In jedem Sprint entwickelt das Team eine Ausgabe des Magazins. Im Sprint Planning zu Beginn des Produktionszyklus treffen sich alle Teammitglieder, um die Ausgabe zu planen: Ein Titelthema wird ausgewählt und die Redakteur*innen ziehen sich die Artikel, an denen sie arbeiten werden. Innerhalb des Sprints gestalten sie zudem mit den Grafiker*innen das Layout der Seiten, suchen Bilder aus und setzen Infografiken ein. Die Anzeigenverkäufer*innen nehmen die Themen der Ausgabe als Aufhänger, um Anzeigenkund*innen zu akquirieren.

Der Sprintzyklus in der Zeitschriftenproduktion

Im täglichen 15-minütigen Redaktionsmeeting (Daily Standup) hält sich das Team auf dem Laufenden: Wo hakt es gerade? Wer benötigt weitere Informationen? Wer kennt eventuell einen kompetenten Interviewpartner für ein Thema der Ausgabe? Parallel zur Produktion prasselt eine Beschwerde ein: Ein Unternehmen fühlt sich in der letzten Ausgabe falsch dargestellt und verlangt eine Gegendarstellung. PO Claudia spricht dies im Daily an und möchte das Thema mit in die Ausgabe nehmen. Scrum Master Michael hält dagegen und möchte den Sprint schützen. Im Gespräch mit Claudia suchen sie gemeinsam nach einer Lösung: Ist die Gegendarstellung so wichtig, dass sie ins Heft aufgenommen und der Backlog während des laufenden Sprints neu sortiert wird? Und welches geplante Thema wird dafür aufgegeben? Oder kann die Gegendarstellung in die nächste Ausgabe übernommen werden? Sie beschließen, die Gegendarstellung zu verschieben. PO Claudia tritt mit dem beschwerenden Unternehmen in Verbindung und erläutert die Entscheidung.

Sales Manager Mesut schlägt Alarm: Kunde Firma Müller hat seine bis Ende des Jahres gebuchten Anzeigenplätze storniert und der Verkauf für die aktuelle Ausgabe verläuft stockend. Scrum Master Michael schließt sich mit Mesut und den drei Sales-Kolleg*innen in einem eintägigen Workshop zusammen, um alternative Finanzierungsmöglichkeiten zu erörtern.

Team nimmt Feedback in Sprint-Review auf 

Redaktionsschluss: Es ist vollbracht. Die Ausgabe ist fertig und kann in Druck gehen. Parallel zur Veröffentlichung veranstaltet das Team im Rahmen ihrer Sprint Review eine öffentliche Blattkritik, an der auch Leser*innen und andere Stakeholder aus dem Verlag (z. B. Geschäftsführung und Vertriebsteam) teilnehmen. Das Team präsentiert die aktuelle Ausgabe und nimmt Feedback und Verbesserungsvorschläge auf: Vertriebsmitarbeiterin Cordula hätte in der Zukunft gerne eine reißerischere Titelseite, um den Absatz am Kiosk zu steigern. Leser Fritz wünscht sich eine tiefere Analyse von Thema Y und abwechslungsreichere Darstellungsformate im Magazin.

Am Ende des aktuellen Sprints und vor Beginn der nächsten Ausgabe trifft sich das Team zu einer Sprint Retrospektive. Während in der Review die Ergebnisse des letzten Sprints (die aktuelle Ausgabe) im Fokus stand, bezieht sich die Retrospektive auf die Zusammenarbeit. Scrum Master Michael führt durch das Meeting und notiert die Ideen und Verbesserungsvorschläge, die hier gesammelt werden: Was haben wir bei der Produktion der aktuellen Ausgabe gelernt? Was können wir beim nächsten Mal besser machen? Und wie können wir das Feedback aus der Sprint Review aufnehmen? Die Retrospektive schließt den aktuellen Sprintzyklus ab. Das Magazin liegt am Kiosk und in den Briefkästen der Abonnent*innen. Nun kann der nächste Sprint beginnen.

Fazit: die verteilte Verantwortung der Scrum-Rollen 

Scrum eignet sich vor allem in der fortlaufenden Produktentwicklung und bei Projekten mit längerer Dauer. Entstanden in der Softwareentwicklung verwenden heutzutage Teams aus vielen unterschiedlichen Bereichen das agile Framework. Scrum arbeitet in kurzen Planungszyklen: In den Sprints können komplexe Projekte oder Produkte in einem inkrementellen Ansatz entwickelt werden.

Das Scrum-Team besteht aus den Scrum-Rollen Product Owner, Scrum-Master und Entwickler*innen. Alle Mitglieder agieren auf Augenhöhe und verteilen die Verantwortung für die Aufgaben auf die drei Teamrollen. Das Scrum-Team ist eine „geschlossene Einheit von Fachleuten“, das an einem gemeinsamen Ziel arbeitet.

NACH OBEN