Scrum Framework: Rollen, Events und Artefakte erklärt (mit Beispielen)

Die meisten Menschen lernen Scrum falsch. Sie behandeln es als Checkliste von Meetings, die geplant werden müssen, und Rollen, die vergeben werden sollen, führen ein paar Sprints durch und fragen sich dann, warum das Team immer noch langsam liefert und der Product Backlog nie kleiner wird. Das Scrum Framework ist keine Methodik, die man einmal einführt und dann vergisst. Es ist eine Feedback-Schleife, die man in jedem einzelnen Sprint anpasst, und dieser Unterschied ist enorm wichtig.

Scrum ist bewusst schlank. Es gibt gerade genug Struktur, um Probleme schnell sichtbar zu machen und sie zu beheben, bevor sie sich potenzieren. Die Teams, die echten Nutzen daraus ziehen, sind jene, die das Inspect-and-Adapt-Prinzip ernst nehmen, nicht jene, die ihre Stand-ups einfach in "Daily Scrum" umbenennen.

Was ist das Scrum Framework?

Scrum ist ein schlankes Agile Framework zur Lieferung komplexer Produkte durch kurze, zeitgebundene Iterationen, die Sprints. Es schreibt keine spezifischen Engineering-Praktiken oder Tools vor. Stattdessen definiert es ein minimales Set an Rollen, Events und Artefakten, das Transparenz schafft, häufige Inspektion ermöglicht und Anpassung beschleunigt.

Jeff Sutherland und Ken Schwaber entwickelten Scrum Anfang der 1990er Jahre auf der Grundlage von Konzepten aus der Lean-Produktion und der empirischen Prozesssteuerung. Sie präsentierten es erstmals öffentlich auf der OOPSLA-Konferenz 1995. Der erste formale Scrum Guide wurde 2010 veröffentlicht. Die aktuellste Version, der Scrum Guide 2020, hat das Framework noch weiter vereinfacht, vorschreibende Elemente entfernt und den Fokus auf die drei Säulen des Empirismus geschärft: Transparenz, Inspektion und Anpassung.

Lean-Denken zieht sich durch das gesamte Framework. Scrum Teams beseitigen Verschwendung, indem sie in kurzen Zyklen arbeiten, echtes Feedback zu funktionierender Software einholen und Arbeit stoppen, die das Produkt nicht seinem Ziel näherbringt.

Key Facts

• Sutherland und Schwaber präsentierten Scrum erstmals öffentlich auf der OOPSLA-Konferenz 1995 und stellten dabei das Konzept zeitgebundener Iterationen mit definierten Rollen vor.
• Der Scrum Guide 2020 (verfügbar unter scrumguides.org) ist die maßgebliche Quelle. Er entfernte den Begriff "Development Team" und vereinfachte das Framework im Vergleich zu früheren Versionen erheblich.
• Laut dem 17th State of Agile Report (Digital.ai, 2023) ist Scrum nach wie vor der am häufigsten eingesetzte Agile Ansatz, wobei 87 % der Agile Teams Scrum oder ein Scrum-Hybrid nutzen.

Der Scrum-Zyklus visualisiert

Der Scrum-Zyklus ist eine empirische Schleife. Er beginnt mit dem Product Backlog, einer geordneten Liste aller Dinge, an denen das Team möglicherweise arbeiten könnte. Jeder Zyklus beginnt mit der Sprint-Planung, bei der das Team Einträge aus dem Product Backlog auswählt und einen Sprint Backlog erstellt, also die spezifische Arbeit, die im kommenden Sprint erledigt werden soll.

Der Sprint selbst dauert ein bis vier Wochen. Während dieser Zeit hält das Team täglich einen Daily Scrum ab: ein 15-minütiges Koordinationsmeeting, bei dem Developers den Fortschritt in Richtung Sprint-Ziel überprüfen und ihre Arbeit für die nächsten 24 Stunden neu planen.

Am Ende des Sprints liefert das Team ein funktionierendes Increment, etwas, das der Definition of Done entspricht und grundsätzlich veröffentlicht werden könnte. Das Sprint-Review ist eine informelle Sitzung, bei der Team und Stakeholder das Increment begutachten und besprechen, was als Nächstes zu tun ist. Danach folgt die Sprint-Retrospektive, bei der das Team sich selbst betrachtet: wie es gearbeitet hat, was verbessert werden soll und was in den nächsten Sprint mitgenommen werden soll.

Und dann wiederholt es sich. Product Backlog, Sprint-Planung, Sprint, Increment, Review, Retrospektive, Product Backlog. Die Schleife ist das Framework. Sie ist kurz, damit Fehler günstig und das Lernen schnell sind.

Die 3 Scrum-Rollen (das Scrum Team)

Der Scrum Guide 2020 hat das Konzept von Unterteams abgeschafft. Es gibt ein Scrum Team, keine Hierarchie, und drei Verantwortungsbereiche darin.

Product Owner

Der Product Owner ist dafür verantwortlich, den Wert des Produkts zu maximieren. Er besitzt den Product Backlog, erstellt ihn, ordnet ihn und stellt sicher, dass die Developers verstehen, was darin enthalten ist. Eine wichtige Einschränkung aus dem Scrum Guide: Der Product Owner ist eine einzelne Person, kein Komitee. Entscheidungen darüber, was gebaut wird, müssen von einer einzigen Stimme kommen.

In der Praxis arbeitet der Product Owner an der Schnittstelle von Geschäftsstrategie und Entwicklungsarbeit. Er trifft ständig Urteile: Welche Funktion lohnt es sich als Nächstes zu entwickeln, welchen Nutzerbedarf zu priorisieren, welchen Backlog-Eintrag zu streichen. Ein schwacher Product Owner, der diese Entscheidungen nicht schnell treffen kann, schafft einen Engpass, den das gesamte Scrum Team in jedem Sprint spüren wird.

Der Product Owner ist kein Vermittler und kein Zwischenglied. Wenn Stakeholder etwas wollen, gehen sie über den Product Owner, nicht an ihm vorbei. Respektiert die Organisation diese Grenze nicht, funktioniert Scrum nicht gut.

Scrum Master

Der Scrum Master dient dem Scrum Team und der gesamten Organisation. Er ist für die Wirksamkeit des Teams verantwortlich: Er hilft Developers, gut zusammenzuarbeiten, unterstützt den Product Owner bei Backlog-Techniken, beseitigt Hindernisse und berät die Organisation bei der Scrum-Einführung.

Der Scrum Master ist kein Projektmanager. Er weist keine Aufgaben zu, erfasst keine Stunden und berichtet der Führungsebene nicht über die Teamleistung. Seine Rolle ist eher die eines Coaches und dienenden Anführers. Er schützt das Team vor Ablenkungen, moderiert Events und widersetzt sich, wenn jemand (einschließlich der Unternehmensführung) versucht, das Framework auf eine Weise zu umgehen, die das Team untergräbt.

Ein häufiger Fehler ist, die Scrum-Master-Rolle als Teilzeitaufgabe zu behandeln, die ein Entwickler neben seiner regulären Sprint-Arbeit übernimmt. Das kann bei erfahrenen Teams funktionieren, aber ein Team, das Scrum zum ersten Mal einführt, profitiert von einem dedizierten Scrum Master, der das System tatsächlich beobachten kann.

Developers

Die Developers sind die Personen, die in jedem Sprint das Increment erstellen. Der Scrum Guide 2020 änderte die Bezeichnung von "Development Team" in "Developers", um zu signalisieren, dass die Verantwortung bei allen liegt, die die Arbeit erledigen, nicht bei einem Unterteam.

Developers sind funktionsübergreifend aufgestellt. Das Scrum Team als Ganzes verfügt über alle Fähigkeiten, die zur Lieferung eines funktionierenden Produktinkrements erforderlich sind. Das kann bedeuten, dass Designer, Entwickler, Tester und Autoren alle im selben Team sind, aber der Scrum Guide schreibt kein bestimmtes Skill-Set vor.

Developers besitzen den Sprint Backlog und verwalten ihre eigene Arbeit. Niemand außerhalb des Scrum Teams sagt ihnen, wie sie ihre Arbeit erledigen sollen, oder weist einzelnen Personen Aufgaben zu. Sie entscheiden selbst, wie sie Sprint-Backlog-Einträge in das Increment umwandeln.

Die 5 Scrum Events

Jedes Scrum Event ist zeitgebunden und hat einen klaren Zweck. Die Zeitbindung dient nicht nur der Effizienz. Sie schafft einen vorhersehbaren Rhythmus und erzwingt Entscheidungen. Hier sind alle fünf Events mit ihrer offiziellen maximalen Dauer.

Sprint

Der Sprint ist der Container für alle anderen Scrum Events. Er ist eine Iteration mit fester Länge von einem Monat oder weniger. Während eines Sprints werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden würden. Der Scope kann präzisiert werden, wenn das Team mehr lernt, und der Sprint wird nicht abgebrochen, außer wenn das Sprint-Ziel obsolet wird.

Die konstante Sprint-Länge schafft einen Herzschlag. Das Team weiß, wann die Planung stattfindet, wann das Review ist und wann die nächste Möglichkeit zur Lieferung kommt. Die meisten Teams nutzen zweiwöchige Sprints, obwohl die richtige Länge von der Risikotoleranz, der Häufigkeit von Produktänderungen und dem benötigten Feedback abhängt.

Sprint-Planung

Die Sprint-Planung startet den Sprint und beantwortet zwei Fragen: Was kann in diesem Sprint geliefert werden, und wie wird die Arbeit erledigt? Der Product Owner präsentiert die obersten Einträge des Product Backlogs, und das Team wählt die Arbeit aus, die es für machbar hält.

Das Ergebnis ist das Sprint-Ziel, ein einzelnes Ziel, das dem Sprint Kohärenz gibt, und der Sprint Backlog, die ausgewählten Einträge samt Plan für ihre Umsetzung.

Zeitlimit: bis zu 8 Stunden für einen einmonatigen Sprint. Kürzere Sprints verwenden proportional weniger Zeit.

Daily Scrum

Der Daily Scrum ist ein 15-minütiges Event für Developers, um den Fortschritt in Richtung Sprint-Ziel zu überprüfen und ihren Plan für die nächsten 24 Stunden anzupassen. Es ist kein Statusbericht an den Scrum Master. Es ist Koordination unter Developers.

Der Scrum Guide 2020 entfernte die vorgeschriebenen drei Fragen (Was habe ich gestern getan, was werde ich heute tun, gibt es Hindernisse?) und gab Teams Flexibilität bei der Durchführung, solange der Zweck erfüllt wird. Ziel ist, dass Developers das Meeting mit dem Wissen verlassen, wer was tut und wo die Hindernisse liegen.

Sprint-Review

Das Sprint-Review ist eine Inspektion des Increments und eine Anpassung des Product Backlogs. Das Scrum Team und Stakeholder schauen gemeinsam, was erreicht wurde, besprechen, was sich im Markt oder Geschäft verändert hat, und einigen sich auf das weitere Vorgehen.

Es ist keine Demo, auch wenn Demos dabei stattfinden. Der Unterschied ist bedeutsam: Eine Demo ist eine Präsentation, ein Sprint-Review ist eine Arbeitssitzung. Stakeholder sind kein Publikum, sie sind Teilnehmer.

Zeitlimit: bis zu 4 Stunden für einen einmonatigen Sprint.

Sprint-Retrospektive

Die Sprint-Retrospektive ist der Ort, wo das Scrum Team sich selbst betrachtet. Was lief gut, was nicht, und welche ein oder zwei Dinge werden sie im nächsten Sprint anders machen? Das Ergebnis ist ein konkreter Verbesserungsplan, zu dessen Umsetzung sich das Team verpflichtet.

Dieses Event ist der Motor der kontinuierlichen Verbesserung in Scrum. Teams, die Retrospektiven auslassen oder sie als Formalität behandeln, hören auf, sich zu verbessern. Der Wert wächst mit der Zeit, sodass Teams mit der besten Retrospektivpraxis über ein Jahr oder länger auch die leistungsstärksten Teams sind.

Zeitlimit: bis zu 3 Stunden für einen einmonatigen Sprint.

Die 3 Scrum Artefakte und ihre Verbindlichkeiten

Der Scrum Guide 2020 verknüpfte jedes Artefakt mit einer Verbindlichkeit, einem messbaren Ziel, das dem Artefakt Richtung gibt und anhand dessen der Fortschritt überprüft werden kann.

Product Backlog (Verbindlichkeit: Produktziel)

Der Product Backlog ist eine geordnete, sich kontinuierlich entwickelnde Liste aller Dinge, die zur Produktverbesserung getan werden könnten. Er ist nie vollständig. Neue Einträge werden hinzugefügt, alte entfernt und Prioritäten verschoben, während das Team dazulernt.

Die Verbindlichkeit für den Product Backlog ist das Produktziel: das langfristige Ziel, auf das das Scrum Team hinarbeitet. Jeder Sprint sollte das Produkt dem Produktziel näherbringen, und der Product Backlog beschreibt den Weg dorthin.

Der Product Owner besitzt den Product Backlog und ist für seine Ordnung und Klarheit verantwortlich.

Sprint Backlog (Verbindlichkeit: Sprint-Ziel)

Der Sprint Backlog ist die Menge der für den Sprint ausgewählten Product-Backlog-Einträge, plus den Plan für ihre Lieferung, plus das Sprint-Ziel. Er ist ein Echtzeitbild der Arbeit, die Developers in diesem Sprint erledigen wollen.

Die Verbindlichkeit ist das Sprint-Ziel: ein einzelnes Ziel, das dem Sprint einen Sinn gibt. Wenn während des Sprints neue Arbeit entsteht, fügen Developers sie dem Sprint Backlog nur hinzu, wenn das Sprint-Ziel dadurch nicht gefährdet wird.

Increment (Verbindlichkeit: Definition of Done)

Ein Increment ist ein konkreter Schritt in Richtung Produktziel. Jeder Sprint muss mindestens ein Increment produzieren. Es muss nutzbar sein und den Standards des Teams entsprechen.

Die Verbindlichkeit ist die Definition of Done (DoD): ein gemeinsames Verständnis davon, was "fertig" bedeutet. Wenn ein Eintrag die Definition of Done nicht erfüllt, ist er nicht Teil des Increments. Die DoD schafft Transparenz und Konsistenz. Sie ist keine Checkliste pro Eintrag, sondern ein Qualitätsstandard, der für alle Inkremente gilt.

Auf einen Blick: Rollen, Events und Artefakte

Die 11 Elemente sind alles, was Scrum vorschreibt. Das ist das gesamte Framework. Alles darüber hinaus ist entweder eine ergänzende Praxis (wie Test-Driven Development oder User-Story-Mapping) oder ein organisatorischer Zusatz, der separat verwaltet wird.

Ein typischer 2-Wochen-Sprint-Rhythmus

So sieht ein typischer zweiwöchiger Sprint in der Praxis aus, Tag für Tag.

Tag 1: Sprint-Planung. Das Team trifft sich, bespricht gemeinsam mit dem Product Owner die obersten Product-Backlog-Einträge, setzt das Sprint-Ziel und erstellt den Sprint Backlog. Für einen zweiwöchigen Sprint dauert die Planung typischerweise 2 bis 4 Stunden.

Tage 1 bis 10: Entwicklung. Jeden Tag, einschließlich Tag 1, hält das Team einen 15-minütigen Daily Scrum ab. Developers koordinieren sich, machen Hindernisse sichtbar und planen bei Bedarf um. Der Scrum Master beseitigt Impediments. Der Product Owner steht für Rückfragen zur Verfügung.

Tag 10 Vormittag: Sprint-Review. Das Team präsentiert das Increment den Stakeholdern, holt Feedback ein und aktualisiert den Product Backlog. Das dauert für einen zweiwöchigen Sprint typischerweise 1 bis 2 Stunden.

Tag 10 Nachmittag: Sprint-Retrospektive. Das Scrum Team blickt nach innen. Was hat funktioniert, was nicht, welche Änderungen werden im nächsten Sprint ausprobiert. Bis zu 1,5 Stunden.

Tag 11: Neuer Sprint beginnt. Gleiche Struktur, gleicher Rhythmus, mit ein oder zwei Verbesserungen aus der Retrospektive.

Die Regelmäßigkeit ist der Kern. Wenn jeder Sprint die gleiche Form hat, sinkt der Koordinationsaufwand und das Team kann sich auf die eigentliche Arbeit konzentrieren. Wie Sprint-Rhythmen mit übergeordneten Projektzeitplänen verbunden werden, beschreibt der Leitfaden zur Projektplanung.

Scrum vs. Kanban vs. Waterfall

Scrum wird oft mit Kanban und der traditionellen Waterfall-Methodik verglichen. Die Unterschiede gehen tiefer, als ob man Sprints oder ein Board hat.

Kurz gesagt: Nutzen Sie Scrum, wenn Sie etwas Komplexes bauen und die Anforderungen sich beim Lernen verändern werden. Nutzen Sie Kanban, wenn Arbeit kontinuierlich eingeht und Sie den Fluss statt der Iteration optimieren müssen. Nutzen Sie Waterfall, wenn der Scope fest ist, das Änderungsrisiko gering ist und Sie vorab einen vollständigen Plan benötigen (üblich im Bauwesen, in compliance-intensiven Branchen oder bei Festpreisverträgen).

Viele Teams betreiben ein Scrum-Kanban-Hybrid: Sprint-Rhythmus für geplante Entwicklungsarbeit, Kanban-Board für Bugs und ungeplante Anfragen. Das ist in Ordnung, solange das Team klar hat, welches System welche Arbeit steuert.

Für strukturierte Planungstools, die Scrum ergänzen, siehe Projektstrukturplan, kritischer Pfad, Gantt-Diagramme und PERT-Diagramme.

Häufige Fehler, die Scrum scheitern lassen

Die meisten Scrum-Misserfolge sind keine Framework-Fehler. Es sind Implementierungsfehler. Das sind die häufigsten:

• Sprint-Retrospektive auslassen. Das ist das Event, bei dem Scrum seinen Zinseszinseffekt entfaltet. Teams, die sie auslassen, bleiben dauerhaft auf demselben Dysfunktionsniveau. Bei Zeitknappheit die Retrospektive kürzen, aber nicht streichen.
• Den Scrum Master als Projektmanager behandeln. Aufgaben zuweisen, Velocity an die Führungsebene melden und Zeitpläne verwalten sind PM-Aufgaben. Ein Scrum Master, der diese Jobs macht, erledigt keine Scrum-Master-Arbeit. Beide Rollen leiden darunter.
• Keinen echten Product Owner haben. Ein Product Owner, der keine Priorisierungsentscheidungen treffen kann, die Zustimmung von drei Komitees braucht oder das Sprint-Ziel mitten im Sprint ändert, zerstört die Planungs- und Lieferfähigkeit des Teams.
• Stakeholdern erlauben, den Product Owner zu umgehen. Wenn Developers Funktionsanfragen direkt von Führungskräften oder Kunden erhalten, ist das ein Zeichen, dass die Autorität des Product Owners nicht respektiert wird. Die Unternehmenskultur muss angepasst werden, nicht das Framework.
• Sprints ohne Sprint-Ziel durchführen. Ein Sprint, der nur eine Aufgabenliste ist, hat kein vereinendes Ziel. Das Team kann keine guten Abwägungsentscheidungen treffen, wenn neue Informationen eintreffen, weil es nichts gibt, das es zu schützen gilt.
• Scrum als vollständige Lösung betrachten. Scrum enthält keine Engineering-Praktiken. Teams brauchen außerdem Testautomatisierung, Continuous Integration und klare Qualitätsstandards (die Definition of Done), um tatsächlich funktionierende Inkremente zu liefern. Ohne diese wird das Sprint-Review zu einer Parade halb fertiger Funktionen.

Häufig gestellte Fragen

Ist Scrum dasselbe wie Agile?

Nein. Agile ist ein Satz von Werten und Prinzipien, beschrieben im Agile Manifesto (2001). Scrum ist ein Framework zur Umsetzung dieser Prinzipien. Sie können agil sein ohne Scrum zu nutzen, und Sie können Scrum so schlecht praktizieren, dass es Agile-Werten widerspricht. Agile ist die Philosophie, Scrum ist eine strukturierte Möglichkeit, sie zu praktizieren. Weitere Agile Frameworks sind Kanban, Extreme Programming (XP) und SAFe (Scaled Agile Framework).

Kann Scrum ohne einen Scrum Master funktionieren?

Technisch gesehen erfordert Scrum einen Scrum Master. In der Praxis arbeiten reife Teams manchmal ohne einen dedizierten Scrum Master, indem sie die Coaching- und Moderationsverantwortung auf Teammitglieder verteilen. Teams, die Scrum zum ersten Mal einführen, brauchen jedoch typischerweise einen Scrum Master, der aktiv das Framework schützt, das Team coacht und organisatorische Hindernisse beseitigt. Ohne diese Rolle neigen Teams dazu, in alte Gewohnheiten zurückzufallen: Stand-ups werden zu Statusmeetings, Retrospektiven werden übersprungen und der Product Owner verliert seine Backlog-Autorität.

Wie lang sollte ein Sprint sein?

Der Scrum Guide 2020 sagt: ein Monat oder weniger, wobei die meisten Teams ein bis vier Wochen wählen. Zweiwöchige Sprints sind in der Praxis am häufigsten. Die richtige Länge hängt davon ab, wie stabil die Anforderungen sind, wie oft das Team externes Feedback benötigt und wie viel Planungsaufwand das Team verkraften kann. Kürzere Sprints bedeuten schnelleres Feedback, aber mehr Planungszeremonien im Verhältnis zur Entwicklungszeit. Längere Sprints reduzieren den Zeremonienaufwand, verzögern aber das Feedback. Mit zwei Wochen beginnen und basierend auf dem Gelernten anpassen.

Was wurde im Scrum Guide 2020 entfernt?

Die Revision von 2020 entfernte mehrere Dinge, die sich in früheren Versionen angesammelt hatten. Die drei vorgeschriebenen Daily-Scrum-Fragen ("Was habe ich gestern getan, was werde ich heute tun, gibt es Hindernisse?") wurden zugunsten flexibler Formate entfernt. Der Begriff "Development Team" wurde durch "Developers" ersetzt. Das Konzept des Chief Product Owners und des Sprint 0 wurde gestrichen. Die Rolle des Scrum Masters als "dienender Anführer" wurde zu "wahrer Anführer" umformuliert. Der Guide von 2020 fügte außerdem erstmals die drei Artefaktverbindlichkeiten (Produktziel, Sprint-Ziel, Definition of Done) hinzu, was neue Ergänzungen waren und keine Streichungen.

Scrum wird sich weiterentwickeln. Das ist der Sinn. Das Framework selbst praktiziert, was es predigt: Inspect, Adapt und eine schlankere Version liefern.

Für Teams, die eine RACI-Matrix neben ihren Scrum-Rollen nutzen möchten: RACI eignet sich gut zur Abbildung von Entscheidungsrechten über Stakeholder hinweg, während Scrum-Rollen Verantwortlichkeiten innerhalb des Teams definieren. Beide Frameworks ergänzen sich, anstatt in Konflikt zu stehen.