Was ist Scrum?

Scrum ist ein leichtgewichtiges agiles Rahmenwerk, mit dem kleine Teams komplexe Produkte über kurze, zeitlich begrenzte Iterationen, sogenannte Sprints, ausliefern. Es definiert drei Rollen (Product Owner, Scrum Master, Entwickler), drei Artefakte (Product Backlog, Sprint Backlog, Inkrement) und fünf Ereignisse, die zusammen einen kontinuierlichen Kreislauf aus Planung, Umsetzung, Überprüfung und Anpassung bilden.

TL;DR

Gemacht für komplexe Arbeit: Scrum ist für Probleme konzipiert, bei denen sich Anforderungen schneller ändern, als sie vorab vollständig spezifiziert werden können.
Sprints sind der Motor: Zeitlich fixierte Iterationen von einer bis vier Wochen zwingen Teams dazu, ein nutzbares Inkrement auszuliefern und auf Basis echter Evidenz neu zu planen.
Drei Rollen, kein Projektmanager: Der Product Owner verantwortet den Wert, der Scrum Master den Prozess und die Entwickler entscheiden, wie die Arbeit umgesetzt wird.
Empirie statt Vorhersage: Transparenz, Überprüfung und Anpassung ersetzen Gantt-Diagramme als Steuerungsmechanismus.

Definition: Scrum ist ein agiles Rahmenwerk zur Steuerung und Umsetzung komplexer Projekte, häufig in der Softwareentwicklung eingesetzt, aber auf jeden Arbeitsbereich übertragbar.

Wie Schwaber und Sutherland Scrum formalisiert haben

Eingeführt wurde Scrum erstmals 1986 von Hirotaka Takeuchi und Ikujiro Nonaka in ihrem Artikel "The New New Product Development Game" in der Harvard Business Review. Das Rahmenwerk ist von einer Strategie inspiriert, bei der ein Team intensiv zusammenarbeitet, um inkrementell auszuliefern, ähnlich wie eine Rugby-Mannschaft den Ball über das Feld bewegt. Ken Schwaber und Jeff Sutherland formalisierten es in den 1990er Jahren, präsentierten 1995 auf der OOPSLA-Konferenz den "SCRUM Software Development Process" und verfassten später gemeinsam den Scrum Guide, der bis heute die maßgebliche Spezifikation darstellt.

Scrum ist ein leichtgewichtiges Rahmenwerk, das Menschen, Teams und Organisationen hilft, durch adaptive Lösungen für komplexe Probleme Wert zu erzeugen.

― Ken Schwaber und Jeff Sutherland, The Scrum Guide (2020)

Laut dem 17th State of Agile Report (2024) bleibt Scrum die meistgenutzte Methodik auf Team-Ebene: 63 Prozent der agilen Praktiker setzen es als primäres Rahmenwerk ein.

Die drei Säulen, auf denen Scrum steht

Scrum ruht auf drei empirischen Säulen, die regeln, wie das Rahmenwerk Risiken in komplexer Arbeit beherrscht:

Transparenz: Alle Aspekte des Prozesses müssen für die Verantwortlichen des Ergebnisses sichtbar sein.
Überprüfung: Teams überprüfen regelmäßig die Scrum-Artefakte und den Fortschritt in Richtung Sprint-Ziel, um unerwünschte Abweichungen früh zu erkennen.
Anpassung: Sobald Aspekte des Prozesses außerhalb akzeptabler Grenzen liegen, passt das Team so schnell wie möglich an, um weiteres Abdriften zu verhindern.

Zusammen ersetzen diese Säulen die Vorab-Planung durch fortlaufende Kurskorrektur, und genau deshalb schlägt Scrum bei komplexen Projekten klassische Wasserfall-Ansätze. Die CHAOS-Studie der Standish Group ergab, dass agile Projekte rund dreimal häufiger erfolgreich sind als Wasserfall-Projekte, wobei sich der Abstand bei größeren Initiativen vergrößert (Standish Group, 2020).

Das Scrum-Team: Drei Rollen im Vergleich

Ein Scrum-Team besteht aus drei Kernrollen mit nicht überlappenden Verantwortlichkeiten. Die Tabelle zeigt, wer wofür verantwortlich ist:

Rolle	Primäre Verantwortung	Entscheidet	Entscheidet nicht
Product Owner	Maximierung des Produktwerts	Was gebaut wird und in welcher Reihenfolge	Wie die Arbeit umgesetzt wird
Scrum Master	Wirksamkeit des Prozesses	Wie das Team seine Praxis verbessert	Umfang oder technische Lösungen
Entwickler	Auslieferung eines nutzbaren Inkrements pro Sprint	Wie die Arbeit technisch umgesetzt wird	Priorität im Backlog

Sprints und die fünf Scrum-Ereignisse

Scrum organisiert Arbeit in einer Reihe zeitlich begrenzter Iterationen, den sogenannten Sprints, die typischerweise zwischen einer und vier Wochen dauern. Jeder Sprint liefert ein nutzbares Inkrement des Produkts und ist von fünf vorgegebenen Ereignissen umrahmt:

Sprint Planning: Das Team einigt sich auf ein Sprint-Ziel und wählt Product-Backlog-Einträge aus, mit denen es dieses Ziel erreichen will.
Daily Scrum: Eine 15-minütige tägliche Abstimmung, in der die Entwickler die nächsten 24 Stunden in Richtung Sprint-Ziel neu planen.
Sprint Review: Das Team präsentiert das fertige Inkrement den Stakeholdern und aktualisiert das Product Backlog auf Basis des Feedbacks.
Sprint Retrospektive: Das Team prüft, wie der letzte Sprint lief, und verpflichtet sich auf konkrete Prozessverbesserungen.
Der Sprint selbst: Das Rahmenereignis, das die vier anderen und die eigentliche Entwicklungsarbeit umschließt.

Der feste Rhythmus ist genau der Punkt. Indem Scrum in jedem Sprint ein funktionierendes Inkrement erzwingt, verwandelt es vage Anforderungen in konkretes Feedback, auf das das Team reagieren kann.

Die drei Artefakte, die Arbeit sichtbar machen

Scrum nutzt drei Artefakte, um Arbeit und Fortschritt für das ganze Team sichtbar zu machen:

Product Backlog: Eine geordnete Liste aller bekannten Anforderungen an das Produkt, verwaltet vom Product Owner.
Sprint Backlog: Die Menge der für den Sprint ausgewählten Product-Backlog-Einträge, zusammen mit einem Plan zur Lieferung des Inkrements und des Sprint-Ziels.
Inkrement: Die Summe aller während eines Sprints und aller vorherigen Sprints abgeschlossenen Product-Backlog-Einträge, in nutzbarem Zustand.

An jedem Artefakt hängt eine Verpflichtung (Product Goal, Sprint Goal, Definition of Done), die das Team an Ergebnisse statt an Aktivität bindet.

Was Scrum für Teams tatsächlich verbessert

Teams, die Scrum gut umsetzen, berichten von Fortschritten in vier Bereichen, für die das Rahmenwerk konkret gebaut ist:

Schnellere Reaktion auf Veränderung. Sprint-weise Neuplanung erlaubt Teams, Prioritäten zu verschieben, ohne einen Quartalsplan komplett zu verwerfen.
Frühere Risikoerkennung. Ein auslieferbares Inkrement pro Sprint bringt Integrations-, Scope- und Qualitätsprobleme ans Licht, solange sie noch günstig zu beheben sind.
Engere Abstimmung mit Stakeholdern. Sprint Reviews ersetzen Statusberichte durch funktionierende Software, was die Erwartungen der Stakeholder geerdet hält.
Stärkere Team-Verantwortung. Selbstmanagende Teams entscheiden, wie die Arbeit umgesetzt wird, was laut Scrum.org-Forschung 2024 mit höherem Engagement und besserer Bindung einhergeht.

Diese Effekte summieren sich. Ein Team, das alle zwei Wochen ausliefert, sammelt rund 26 Feedback-Schleifen pro Jahr, im Vergleich zu vier bis sechs in einem quartalsbasierten Wasserfall-Plan.

Wo Scrum-Einführungen typischerweise scheitern

Die meisten gescheiterten Scrum-Implementierungen brechen an denselben vorhersehbaren Stellen:

Die Product-Owner-Rolle ist aufgeteilt oder unbesetzt. Wenn "Product Owner" ein Gremium oder eine Teilzeit-Analystin ist, wird Backlog-Priorisierung zu Politik statt zu Wertschöpfung.
Daily Scrums werden zu Status-Meetings. Wenn Entwickler an den Scrum Master berichten, statt gemeinsam neu zu planen, verliert das Ereignis seinen Sinn.
Sprints sind in der Praxis nicht zeitlich begrenzt. Einen Sprint zu verlängern, um Arbeit "fertigzubekommen", hebelt den empirischen Steuerungsmechanismus aus.
Keine Definition of Done. Ohne geteilte Messlatte heißt "Inkrement" das, was jede Entwicklerin gerade dafür hält, und die Qualität sinkt.
Retrospektiven führen zu keiner Handlung. Eine Retrospektive, die im nächsten Sprint nicht mindestens eine Praxis verändert, ist Theater.

Das Scrum-Rahmenwerk selbst scheitert selten. Was scheitert, ist die halbe Einführung, bei der Teams die Zeremonien beibehalten, aber die Verantwortungsstruktur, die diese Zeremonien nützlich macht, fallenlassen.

Wann Scrum nicht passt

Scrum ist die Standardwahl für komplexe Produktarbeit, in einigen spezifischen Kontexten aber die falsche:

Reine Flussarbeit ohne Batching-Nutzen. Support-Tickets, Content-Moderation und Ops-Queues sind meist besser bei Kanban aufgehoben, das auf Durchlaufzeit statt Sprint-Rhythmus optimiert.
Regulatorische oder Compliance-Arbeit mit harten Deadlines. Wenn Scope, Reihenfolge und Lieferergebnis durch Regulierung festgelegt sind, fügt Scrums Annahme eines sich entwickelnden Umfangs nur Overhead hinzu, ohne Wert zu schaffen.
Einzelne oder Paare. Scrums Ereignisse sind auf Teams von drei bis neun Personen kalibriert. Darunter überwiegen die Kosten der Zeremonien den Nutzen empirischer Steuerung.
Wirklich einfache, wiederholbare Arbeit. Wenn die Anforderungen stabil sind und der Weg bekannt ist, ist klassisches Projektmanagement günstiger.

Die Wahl des richtigen Rahmenwerks ist eine Entscheidung der Strategieumsetzung, keine Methodikpräferenz. Teams, die Scrum mit OKRs kombinieren, nutzen OKRs typischerweise, um das Sprint Goal und das Product Goal zu setzen, sodass Ergebnisse oberhalb des Iterationsrhythmus sichtbar bleiben.

Scrum außerhalb der Softwareentwicklung

Scrum hat seinen Ursprung in der Softwareentwicklung, die Prinzipien lassen sich aber auf jedes Feld mit komplexer Arbeit und veränderlichen Anforderungen übertragen. Marketing-Teams nutzen Scrum für Kampagnenzyklen, HR-Teams für Recruiting-Initiativen und Produktdesign-Teams für die Übergabe zwischen Research und Launch. Die Mechanik passt sich an. Die empirische Schleife nicht.

Häufig gestellte Fragen

Sind Scrum und Agile dasselbe?

Nein. Agile ist eine Menge von Werten und Prinzipien, festgehalten im Agilen Manifest von 2001. Scrum ist ein konkretes Rahmenwerk, das diese Prinzipien umsetzt. Kanban, Extreme Programming und SAFe sind weitere agile Rahmenwerke.

Wie lang sollte ein Sprint sein?

Der Scrum Guide erlaubt Sprints von einer bis vier Wochen, die meisten Teams landen bei zwei Wochen. Kürzere Sprints liefern schneller Feedback, erhöhen aber den Zeremonien-Aufwand, während längere Sprints den Aufwand senken, aber das Risiko vergrößern, das Falsche zu bauen.

Was unterscheidet einen Scrum Master von einem Projektmanager?

Ein Projektmanager verantwortet Umfang, Zeitplan und Budget. Ein Scrum Master verantwortet die wirksame Nutzung von Scrum im Team und räumt Hindernisse aus, leitet die Arbeit aber nicht an und besitzt das Lieferergebnis nicht. Product Owner und Entwickler teilen sich die Arbeit, die sonst ein Projektmanager übernehmen würde.

Funktioniert Scrum mit OKRs?

Ja. Die meisten Teams nutzen OKRs auf Quartalsebene, um Ergebnisse zu setzen, und Scrum auf Sprint-Ebene, um sie zu liefern. Das Product Goal in Scrum lässt sich sauber auf ein OKR-Objective abbilden.

Was ist eine Definition of Done?

Eine Definition of Done ist der geteilte Standard, den ein Product-Backlog-Eintrag erfüllen muss, um als Teil des Inkrements zu gelten. Sie umfasst typischerweise Code-Review, bestandene automatisierte Tests, aktualisierte Dokumentation und Deployment auf eine Staging-Umgebung. Ohne sie ist "fertig" undefiniert.

Wie groß sollte ein Scrum-Team sein?

Der Scrum Guide 2020 empfiehlt zehn Personen oder weniger. Teams mit mehr als neun Mitgliedern verlieren typischerweise den Zusammenhalt, der Daily Scrums und Sprint Planning wirksam macht, und werden meist besser in mehrere Scrum-Teams an einem gemeinsamen Product Goal aufgeteilt.