Scrum

Scrum bezeichnet ein agiles Rahmenwerk (englisch: Framework) zur Entwicklung, Lieferung und Pflege komplexer Produkte. Es basiert auf iterativer, inkrementeller Arbeit in festen Zeitabschnitten – sogenannten Sprints. Dabei definiert es klare Rollen, Ereignisse und Artefakte. Ursprünglich für die Softwareentwicklung konzipiert, wird Scrum heute branchenübergreifend eingesetzt.

Herkunft und Grundidee von Scrum

Der Begriff stammt aus dem Rugby und bezeichnet das Gedränge, bei dem ein Team gemeinsam um den Ball kämpft. In die Softwareentwicklung eingeführt wurde das Konzept in den frühen 1990er Jahren von Jeff Sutherland und Ken Schwaber. Beide veröffentlichten 1995 ein erstes wissenschaftliches Papier über das Framework. Außerdem gehörten sie 2001 zu den Mitunterzeichnern des Agilen Manifests – eines einflussreichen Dokuments mit zwölf Prinzipien für flexible, kundenzentrierte Produktentwicklung.

Der Kern der Scrum-Idee ist empirische Prozesssteuerung: Entscheidungen beruhen auf Beobachtung, Erfahrung und Experiment – nicht auf starren Plänen. Drei Säulen tragen dieses Prinzip: Transparenz (alle relevanten Informationen sind sichtbar), Inspektion (regelmäßige Überprüfung des Fortschritts) und Adaption (Anpassung bei Abweichungen vom Ziel).

Die drei Scrum-Rollen

Das Framework definiert drei klar abgegrenzte Verantwortlichkeiten. Zusammen bilden sie das Scrum Team.^[1] Jede Rolle hat einen spezifischen Aufgabenbereich. Dieser ist nicht hierarchisch, sondern komplementär angelegt.

Scrum im Überblick: Die drei Kernrollen

Der Product Owner verantwortet das Product Backlog – eine priorisierte Liste aller Anforderungen und Funktionen des Produkts. Er trifft inhaltliche Entscheidungen darüber, welche Aufgaben als nächstes umgesetzt werden. Dabei repräsentiert er die Interessen der Stakeholder gegenüber dem Entwicklungsteam. Konzepte wie das Minimum Viable Product spielen häufig eine wichtige Orientierungsrolle, um frühzeitig lieferbaren Wert zu schaffen.

Der Scrum Master ist kein klassischer Projektleiter, sondern ein Servant Leader. Er unterstützt das Team dabei, das Framework korrekt anzuwenden. Zudem räumt er Hindernisse aus dem Weg und schützt das Team vor äußeren Störungen. Der Scrum Master moderiert die vorgeschriebenen Ereignisse und fördert eine Kultur der kontinuierlichen Verbesserung.

Die Developer (früher: Development Team) erstellen gemeinsam ein lieferbares Produktinkrement. Sie sind selbstorganisiert und entscheiden eigenständig, wie sie Anforderungen technisch umsetzen. Typischerweise hat ein Scrum-Team zwischen drei und neun Entwicklerinnen und Entwickler.

Ereignisse und Ablauf eines Sprints

Scrum strukturiert die Arbeit in zeitlich begrenzte Iterationen, die Sprints genannt werden. Ein Sprint dauert in der Regel ein bis vier Wochen. Er endet stets mit einem nutzbaren Produktinkrement. Innerhalb jedes Sprints gibt es vier fest definierte Ereignisse:

Sprint Planning: Das Team plant gemeinsam, welche Einträge aus dem Product Backlog umgesetzt werden. Dabei definiert es ein Sprint-Ziel.
Daily Scrum: Ein tägliches, auf 15 Minuten begrenztes Treffen. Das Entwicklungsteam synchronisiert seinen Fortschritt und identifiziert Hindernisse.
Sprint Review: Am Sprintende präsentiert das Team den Stakeholdern das fertige Inkrement und erhält Feedback, das in das Product Backlog einfließt.
Sprint Retrospective: Das Team reflektiert seinen eigenen Arbeitsprozess und leitet konkrete Verbesserungsmaßnahmen ab.

Dieser feste Rhythmus aus Planung, Ausführung und Reflexion unterscheidet Scrum grundlegend von klassischen, phasenbasierten Vorgehensmodellen wie dem Wasserfallmodell.

Artefakte: Product Backlog, Sprint Backlog und Inkrement

Scrum kennt drei zentrale Artefakte.^[2] Sie sollen Transparenz über Arbeit und Fortschritt herstellen. Jedem Artefakt ist eine sogenannte Commitment zugeordnet, die seinen Zweck konkretisiert.

Das Product Backlog ist eine dynamische, priorisierte Gesamtliste aller Anforderungen, Verbesserungen und Fehlerbehebungen. Es wird kontinuierlich gepflegt (Backlog Refinement). Das zugehörige Commitment ist das Product Goal – ein langfristiges Ziel für das Produkt.

Das Sprint Backlog enthält die für den laufenden Sprint ausgewählten Einträge. Außerdem beschreibt es, wie das Team das Sprint-Ziel erreichen will. Es gehört dem Entwicklungsteam und wird täglich aktualisiert. Sein Commitment ist das Sprint Goal.

Das Inkrement ist das Ergebnis eines Sprints – ein nutzbares, potenziell auslieferbares Produktstück. Das zugehörige Commitment ist die Definition of Done. Diese legt präzise fest, welche Qualitätsstandards erfüllt sein müssen, damit eine Aufgabe als abgeschlossen gilt.

Verbreitung und Anwendungsbereiche

Scrum ist weltweit das am häufigsten eingesetzte agile Framework. In Deutschland setzt laut einer Befragung von Bitkom Research die Mehrheit agil arbeitender Unternehmen auf dieses Framework.^[3] Obwohl ursprünglich für die Softwareentwicklung konzipiert, findet es heute auch in Marketingabteilungen, Produktentwicklung, Forschung und Bildung Anwendung.

Für die praktische Umsetzung spielen digitale Projektmanagement-Tools eine wichtige Rolle. Spezialisierte Anwendungen unterstützen Teams beim Verwalten von Backlogs, beim Visualisieren von Sprints und beim Nachverfolgen von Fortschritten in Echtzeit. Zu den verbreiteten Werkzeugen zählen Jira, Azure DevOps und kartenbasierte Systeme.

Ein wesentlicher Erfolgsfaktor ist die Teamgröße. Zu große Teams verlieren die Vorteile der Selbstorganisation. Der offizielle Scrum Guide empfiehlt daher ein Gesamtteam von nicht mehr als zehn Personen.

Abgrenzung zu verwandten Frameworks

Scrum wird oft mit anderen agilen Methoden verglichen oder kombiniert. Die wichtigsten Abgrenzungen betreffen Kanban, Extreme Programming (XP) und skalierte Frameworks.

Merkmal	Scrum	Kanban
Zeitstruktur	Feste Sprints (1–4 Wochen)	Kontinuierlicher Fluss, keine Sprints
Rollen	Product Owner, Scrum Master, Developer	Keine vorgeschriebenen Rollen
Änderungen im Prozess	Erst im nächsten Sprint möglich	Jederzeit möglich
Geeignet für	Produktentwicklung mit klaren Iterationen	Support, Operations, laufende Prozesse

Extreme Programming (XP) teilt mit Scrum den iterativen Ansatz, betont aber technische Praktiken wie testgetriebene Entwicklung oder Pair Programming. Beide Methoden lassen sich kombinieren – bekannt als ScrumXP.

Für größere Organisationen gibt es skalierte Varianten. Beispiele sind SAFe (Scaled Agile Framework), LeSS (Large-Scale Scrum) und Nexus. Sie koordinieren mehrere Scrum-Teams, die gemeinsam an einem Produkt arbeiten.

Grenzen und Kritik

Obwohl Scrum in vielen Kontexten bewährt ist, stößt das Framework auch an Grenzen. Kritiker bemängeln, dass formale Rollen und Ereignisse in manchen Organisationen zu bürokratischem Overhead führen. Dieses Phänomen wird als Cargo-Cult-Scrum bezeichnet: Teams übernehmen die äußere Form, ohne das zugrundeliegende Denken zu verinnerlichen.

Scrum ist außerdem auf stabile, selbstorganisierte Teams ausgelegt. Bei hoher Fluktuation oder in stark regulierten Umgebungen – etwa Medizintechnik oder Luft- und Raumfahrt – müssen erhebliche Anpassungen vorgenommen werden. Hier sind klassische oder hybride Ansätze oft besser geeignet.

Das Framework entfaltet seinen vollen Nutzen nur, wenn alle Beteiligten die agilen Werte Offenheit, Fokus, Mut, Respekt und Commitment tatsächlich leben. Eine rein formale Einführung von Scrum reicht dafür nicht aus.

Literaturempfehlungen

Ken Schwaber, Jeff Sutherland: The Scrum Guide. Scrum.org, 2020 (kostenlos verfügbar unter scrum.org).
Jeff Sutherland: Scrum: The Art of Doing Twice the Work in Half the Time. Crown Business, New York 2014, ISBN 9788408246626.
Boris Gloger: Scrum – Produkte zuverlässig und schnell entwickeln. Hanser, München 2016, ISBN 9783446425156.