Scrum: das verbreitetste agile Rahmenwerk
https://bildung.social/@oerinformatik/
https://oer-informatik.de/scrum
Scrum, Vorgehensmodelle, Scrum Guide, Product Owner, Scrum Master, Developers, Sprint, Product Backlog, Increment, Definition of Done, agile Softwareentwicklung
tl/dr; (ca. 18 min Lesezeit): Scrum ist ein leichtgewichtiges Rahmenwerk für komplexe Produkte: Ein kleines, selbstorganisiertes Team liefert in Sprints von höchstens einem Monat jeweils ein nutzbares Increment und passt Produkt und Zusammenarbeit regelmäßig an. Der Artikel erklärt nach dem Scrum Guide 2020 die drei Verantwortlichkeiten, fünf Ereignisse und drei Artefakte, den Umgang mit Änderungen, den Start eines agilen Projekts, typische Missverständnisse sowie Techniken und Grenzen von Scrum [AI-Assisted]. (Zuletzt geändert am 30.10.2026)
Disclaimer: Teile des Textes stammen von einer KI. Inhalte sind nicht automatisch zuverlässig; überprüfe Fakten und zitiere vertrauenswürdige Quellen.
Dieser Artikel ist Teil einer Artikelreihe über Vorgehensmodelle: Überblick: klassisch und agil / Wasserfallmodell / V-Modell / Spiralmodell / Scrum / Extreme Programming / Kanban / SAFe / DevOps / Übungsaufgaben
Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast.
Dieser Artikel baut auf der Kann-Liste des Artikels Vorgehensmodelle: klassisch und agil auf.
Als Projektmanagement-Grundlagen kann ich nach Durchlesen des Artikels…
… Scrum beschreiben und seine Elemente (Product Owner, Scrum Master, Developers, Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Product Backlog, Sprint Backlog, Increment) erläutern.
… den Ablauf eines Sprints mit seinen Ereignissen und Artefakten darstellen.
… erklären, wie Scrum mit neuen Anforderungen umgeht.
… prüfen, ob vor dem ersten Sprint alles Nötige vereinbart ist.
… Sprint Review und Sprint Retrospective unterscheiden.
… die Definition of Done erklären und ihre Bedeutung für die Qualität begründen.
Darüber hinaus kann ich als Projektmanagement-Expertenwissen…
… typische Missverständnisse über Scrum (z. B. Scrum Master als Chef, Daily als Statusbericht) erkennen und richtigstellen.
… Elemente des Scrum Guides von häufig mit Scrum kombinierten Techniken (User Stories, Story Points, Burndown) unterscheiden.
… beurteilen, wann Scrum ungeeignet ist und wie es sich für mehrere Teams skalieren lässt.
In einem Satz: Scrum zeichnet sich dadurch aus, dass ein kleines, selbstorganisiertes Team in Sprints fester Länge von höchstens einem Monat jeweils ein nutzbares Increment erstellt und Produkt und Vorgehen in festen Ereignissen regelmäßig überprüft und anpasst.
Scrum legt nur wenige, verbindliche Elemente fest: drei Verantwortlichkeiten, fünf Ereignisse und drei Artefakte. Der Ablauf eines Sprints im Überblick:
Herkunft: vom Rugby zum Scrum Guide
Der Name stammt aus dem Rugby (das Gedränge, in dem das ganze Team den Ball gemeinsam vorwärtsbringt). Hirotaka Takeuchi und Ikujiro Nonaka beschrieben 1986 in „The New New Product Development Game“, wie erfolgreiche Unternehmen Produkte mit kleinen, überlappend arbeitenden Teams entwickeln. Ken Schwaber und Jeff Sutherland übertrugen diese Idee auf die Softwareentwicklung und stellten Scrum 1995 auf der Konferenz OOPSLA vor. Seit 2010 beschreiben sie Scrum im Scrum Guide; die aktuelle Fassung stammt von November 2020. Beide gehörten 2001 auch zu den Verfassern des Agilen Manifests. Ziel von Scrum ist, komplexe Produkte mit unsicheren Anforderungen schrittweise, mit häufigem Feedback und hoher Transparenz zu entwickeln. Eingesetzt wird es vor allem in der Produktentwicklung von Software, inzwischen aber auch im Marketing, in der Hardwareentwicklung oder in Schulen.
Grundprinzipien: Empirie, Lean, feste Takte
Scrum beruht auf Empirie (Wissen entsteht aus Erfahrung) und Lean Thinking (Verschwendung vermeiden, auf das Wesentliche konzentrieren). Daraus folgen drei Säulen:
Transparenz: Arbeit und Fortschritt sind für alle sichtbar (Artefakte).
Überprüfung (Inspection): Fortschritt und Artefakte werden regelmäßig geprüft (Ereignisse).
Anpassung (Adaptation): Weicht etwas ab, wird es so schnell wie möglich angepasst.
Dazu kommen fünf Werte: Commitment, Fokus, Offenheit, Respekt und Mut. Besonders an Scrum ist die Kombination aus festem Takt (Sprints gleicher Länge, Timeboxes für alle Ereignisse), Selbstorganisation des Teams und einem Increment, das am Ende jedes Sprints nutzbar ist. Scrum ist ausdrücklich ein Rahmenwerk (framework): Es legt fest, was passiert, aber nicht, wie das Team programmiert, testet oder schätzt.
Ablauf: fünf Ereignisse im Sprint
Sprint: Container für alle anderen Ereignisse; ein Zeitraum fester Länge von höchstens einem Monat (häufig zwei bis vier Wochen). Ein neuer Sprint beginnt direkt nach dem Ende des vorigen. Während des Sprints wird das Sprintziel nicht geändert und die Qualität nicht gesenkt.
Sprint Planning: Zu Beginn legt das Scrum Team fest, warum der Sprint wertvoll ist (Sprintziel), was umgesetzt werden kann (Auswahl aus dem Product Backlog) und wie die Arbeit erledigt wird. Höchstens acht Stunden bei einem einmonatigen Sprint.
Daily Scrum: tägliches Treffen der Developers von höchstens 15 Minuten, immer zur gleichen Zeit am gleichen Ort. Sie prüfen den Fortschritt zum Sprintziel und passen ihre Planung für den nächsten Tag an. Die bekannten drei Fragen („Was habe ich gestern gemacht? Was mache ich heute? Was behindert mich?“) sind eine mögliche Form, seit 2020 aber nicht mehr vorgeschrieben.
Sprint Review: Am Ende des Sprints stellt das Scrum Team den Stakeholdern das Ergebnis vor; gemeinsam wird besprochen, was erreicht wurde und was sich geändert hat. Das Product Backlog wird angepasst. Das Review ist eine Arbeitssitzung, keine reine Präsentation (höchstens vier Stunden bei einem einmonatigen Sprint).
Sprint Retrospective: Zum Abschluss des Sprints reflektiert das Scrum Team seine Zusammenarbeit: Was lief gut, was nicht, was ändern wir im nächsten Sprint? Es geht um Personen, Abläufe, Werkzeuge und die Definition of Done, nicht um das Produkt selbst (höchstens drei Stunden bei einem einmonatigen Sprint).
Daneben verfeinert das Team laufend das Product Backlog (Product Backlog Refinement): Einträge werden zerlegt, präzisiert und geschätzt. Das ist eine fortlaufende Tätigkeit, aber kein eigenes Ereignis. Das Aktivitätsdiagramm zeigt den Ablauf mit den Artefakten, die zwischen den Ereignissen weitergegeben werden:
Rollen: das Scrum Team mit drei Verantwortlichkeiten
Ein Scrum Team ist klein (in der Regel zehn Personen oder weniger), funktionsübergreifend und organisiert sich selbst (der Scrum Guide 2020 nennt das selbstmanagend: Das Team entscheidet selbst, wer woran und wie arbeitet). Es hat keine Hierarchie und keine Unterteams.
Product Owner: verantwortet den Wert des Produkts. Pflegt und priorisiert das Product Backlog, formuliert das Produktziel und spricht mit den Stakeholdern. Es ist eine Person, kein Gremium; sie entscheidet, was als Nächstes entwickelt wird. Für Auftraggebende und Fachabteilungen ist der Product Owner deshalb die Ansprechperson für Anforderungen: Wer einen Wunsch hat, wendet sich an ihn, nicht an einzelne Developers.
Scrum Master: verantwortet, dass Scrum wirksam gelebt wird. Unterstützt Team und Organisation, moderiert bei Bedarf, beseitigt Hindernisse (impediments), schützt das Team vor Störungen. Der Scrum Master ist keine Projektleitung und verteilt keine Aufgaben.
Developers: alle, die im Sprint das Increment erstellen (Programmierung, Test, UX, Datenbank …). Sie planen die Arbeit des Sprints selbst und sind für die Qualität verantwortlich. (Ältere Fassungen sprachen vom Entwicklungsteam.)
Der Scrum Guide spricht seit 2020 bewusst von Verantwortlichkeiten (accountabilities) statt Rollen. Die Teamkultur ist geprägt von Selbstorganisation, gemeinsamer Verantwortung für das Ergebnis und offener Kommunikation. Zusammen ergeben sich die Elemente, die der Scrum Guide verbindlich festlegt:
Artefakte: drei Artefakte und ihre Verpflichtungen
Product Backlog: geordnete Liste aller bekannten Anforderungen und Arbeiten am Produkt, gepflegt vom Product Owner. Die Einträge werden oft als User Stories formuliert („Als Nutzerin möchte ich …, damit …“). Verpflichtung: das Produktziel (Product Goal).
Sprint Backlog: die für den Sprint ausgewählten Einträge plus der Plan der Developers, wie sie umgesetzt werden. Verpflichtung: das Sprintziel (Sprint Goal).
Increment: das im Sprint fertiggestellte, nutzbare Ergebnis, das zu allen früheren Increments passt. Verpflichtung: die Definition of Done, also die gemeinsam festgelegten Qualitätskriterien („getestet, Code-Review erfolgt, dokumentiert, auf dem Testserver installiert …“). Was die Definition of Done nicht erfüllt, ist nicht fertig.
Die Dokumentation ist leichtgewichtig: Scrum verlangt außer diesen drei Artefakten keine Dokumente. Dokumentiert wird, was Wert hat; die Definition of Done kann z. B. ein aktualisiertes Benutzerhandbuch oder eine Schnittstellenbeschreibung ausdrücklich verlangen.
Qualität und Test: die Definition of Done
Scrum schreibt keine Teststrategie vor, verlangt aber, dass jedes Increment die Definition of Done erfüllt. Damit ist Testen keine spätere Phase, sondern Teil jedes Eintrags im Sprint: Was nicht getestet ist, ist nicht fertig. In der Praxis bedeutet das automatisierte Unit- und Integrationstests, Code-Reviews, kontinuierliche Integration und oft Akzeptanzkriterien je User Story. Die Developers sind gemeinsam für die Qualität verantwortlich; eine getrennte Testabteilung am Ende gibt es nicht.
Stakeholder: mindestens einmal pro Sprint
Stakeholder sind über den Product Owner laufend eingebunden und sehen im Sprint Review spätestens nach jedem Sprint das funktionierende Increment. Neue Wünsche kommen nicht in den laufenden Sprint, sondern als neuer Eintrag ins Product Backlog. Der Product Owner priorisiert ihn, und schon im nächsten Sprint Planning kann er umgesetzt werden. So bleibt der Sprint für die Developers planbar, und trotzdem kann das Projekt alle paar Wochen die Richtung ändern. Nur wenn das Sprintziel völlig überholt ist, darf der Product Owner einen Sprint abbrechen.
Bei Let’s Meet könnte das so aussehen: Im Sprint Review zeigt das Team die neue Aktivitätensuche. Eine Testnutzerin im Rollstuhl merkt an, dass sie zuerst wissen muss, ob der Treffpunkt barrierefrei ist. Die Product Owner, Geschäftsführerin Clara Neumann, nimmt einen Filter „barrierefreier Treffpunkt“ als neue User Story ins Product Backlog auf und setzt ihn weit nach oben. Zwei Wochen später ist er online.
Planung und Kontrolle: Sprint für Sprint
Geplant wird auf zwei Ebenen: grob über das Produktziel und das geordnete Product Backlog, genau nur für den nächsten Sprint. Im magischen Dreieck sind damit Zeit (Sprintlänge) und Kosten (Team) fest, der Umfang ergibt sich aus dem, was im Sprint den größten Wert bringt. Transparenz entsteht durch die Artefakte und Ereignisse. Der Scrum Guide schreibt keine Kennzahlen vor; verbreitet sind:
Velocity: wie viele geschätzte Einheiten (z. B. Story Points) ein Team pro Sprint fertigstellt – Grundlage für Prognosen, aber kein Leistungsvergleich zwischen Teams,
Burndown-Chart: verbleibende Arbeit im Sprint (oder bis zum Release) über die Zeit,
Erreichte Sprintziele, Durchlaufzeit von Einträgen und Kundenzufriedenheit.
Skalierung und Anpassbarkeit: mehrere Teams, ein Produkt
Scrum ist für ein Team gemacht. Arbeiten mehrere Teams an einem Produkt, braucht es zusätzliche Abstimmung. Verbreitete Skalierungsrahmen sind Nexus (bis ca. neun Teams, von scrum.org), LeSS (Large-Scale Scrum), Scrum@Scale (von Jeff Sutherland) und das umfassendere SAFe (siehe SAFe). Häufige Anpassungen sind die Kombination mit einem Kanban-Board (Scrumban) oder mit XP-Praktiken. Wichtig: Wer Elemente weglässt (z. B. die Retrospective), arbeitet zwar vielleicht sinnvoll, aber nicht mehr nach Scrum.
Häufig genutzte Techniken
Viele Begriffe werden mit Scrum verbunden, stehen aber nicht im Scrum Guide:
| Technik | wofür | Kern von Scrum? |
|---|---|---|
| User Stories mit Akzeptanzkriterien | Einträge des Product Backlogs formulieren | nein |
| Story Points, Planning Poker | Aufwand relativ schätzen | nein |
| Task Board (Sprint-Board) | Sprint Backlog sichtbar machen | nein |
| Burndown- und Burnup-Charts | Fortschritt sichtbar machen | nein |
| Definition of Ready | Einträge vor dem Sprint Planning vorbereiten | nein |
| testgetriebene Entwicklung, CI | Qualität des Increments sichern | nein |
| Definition of Done | Qualitätskriterien des Increments | ja |
Ein agiles Projekt mit Scrum starten
Wer ein Projekt mit Scrum beginnen will, muss vor dem ersten Sprint einiges vereinbaren. Typische Aktivitäten sind:
Verantwortlichkeiten besetzen: Wer ist Product Owner, wer Scrum Master, wer gehört zu den Developers?
Product Backlog anlegen: erste Anforderungen als User Stories sammeln, schätzen und priorisieren; ein Produktziel formulieren.
Takt festlegen: Sprintlänge (z. B. zwei Wochen) sowie feste Termine für Sprint Planning, Daily Scrum, Sprint Review und Retrospective.
Definition of Done vereinbaren: Wann gilt ein Eintrag als fertig (getestet, Code-Review, dokumentiert …)?
Arbeit sichtbar machen: ein Board (analog oder digital) für das Sprint Backlog einrichten.
Technische Praktiken einführen: z. B. testgetriebene Entwicklung, Versionsverwaltung und kontinuierliche Integration, damit am Sprintende wirklich ein lauffähiges Increment steht.
Während des Projekts wiederholen sich die Ereignisse in jedem Sprint; in der Retrospective wird auch der Ablauf selbst immer wieder verbessert.
Risiken, Stärken und Grenzen
Häufige Stolpersteine sind vor allem falsch verstandene Elemente:
| Missverständnis | richtig ist |
|---|---|
| Der Scrum Master ist der Chef und verteilt die Aufgaben. | Die Developers organisieren sich selbst; der Scrum Master unterstützt und beseitigt Hindernisse. |
| Das Daily Scrum ist ein Statusbericht an die Leitung. | Es ist ein kurzes Planungstreffen der Developers für die nächsten 24 Stunden. |
| Sprints sind so lang, wie die Arbeit eben dauert. | Sprints haben eine feste Länge von höchstens einem Monat; der Umfang passt sich an, nicht die Dauer. |
| Neue Wünsche kommen sofort in den laufenden Sprint. | Neue Wünsche kommen ins Product Backlog und werden ab dem nächsten Sprint berücksichtigt. |
| Im Review geht es um die Zusammenarbeit im Team. | Im Review geht es um das Produkt (mit Stakeholdern), in der Retrospective um die Zusammenarbeit (im Scrum Team). |
| Agil bedeutet: keine Dokumentation. | Dokumentiert wird, was Wert hat; die Definition of Done kann Dokumentation ausdrücklich verlangen. |
Weitere Stolpersteine: ein Product Owner ohne Zeit oder Entscheidungsbefugnis, „Scrum nach Namen“ ohne echte Selbstorganisation (Cargo Cult), Increments, die nie wirklich fertig sind, und Velocity als Druckmittel. Gegenmaßnahmen sind ein erfahrener Scrum Master, ein befugter Product Owner, eine ernst genommene Definition of Done und Retrospektiven mit konkreten Maßnahmen.
Stärken: flexible Reaktion auf neue Wünsche, früher und regelmäßiger Nutzen, hohe Transparenz, kontinuierliche Verbesserung, motivierte Teams durch Selbstorganisation.
Grenzen: Gesamtumfang und -kosten sind zu Beginn unklar; Scrum verlangt Disziplin, Mitarbeit der Auftraggebenden und Erfahrung. Es passt schlecht, wenn Anforderungen feststehen und sich nicht ändern, das Vorhaben sehr klein ist, niemand Product Owner oder Scrum Master sein kann, ein Festpreis mit festem Umfang vereinbart ist oder die Organisation stark hierarchisch geführt wird.
Praxisbeispiele und Anwendungsfelder
Scrum ist das in der Softwarebranche am weitesten verbreitete agile Rahmenwerk: für App- und Webentwicklung, Produktentwicklung mit unklaren Anforderungen, Start-ups und eigene Produkte von Softwarehäusern. Ein Beispiel ist der Neuaufbau der App von Let’s Meet: Die Geschäftsführerin sitzt als Product Owner im Haus, die Nutzenden geben laufend Rückmeldung, und niemand weiß genau, welche Funktionen in einem halben Jahr am wichtigsten sind. Typisch sind Scrum Teams mit insgesamt höchstens etwa zehn Personen (Developers, Product Owner und Scrum Master).
Leitfragen
- Welche Verantwortlichkeiten, Ereignisse und Artefakte legt der Scrum Guide fest?
Drei Verantwortlichkeiten (Product Owner, Scrum Master, Developers), fünf Ereignisse (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) und drei Artefakte (Product Backlog, Sprint Backlog, Increment) mit ihren Verpflichtungen Produktziel, Sprintziel und Definition of Done, siehe Abschnitt „Rollen“, Abschnitt „Ablauf“ und Abschnitt „Artefakte“.
- Wie läuft ein Sprint ab?
Im Sprint Planning legt das Team Sprintziel, Auswahl und Plan fest (Sprint Backlog); dann entwickeln die Developers das Increment und stimmen sich täglich im Daily Scrum ab; am Ende prüfen sie mit den Stakeholdern das Increment im Sprint Review und verbessern in der Retrospective die Zusammenarbeit, danach beginnt sofort der nächste Sprint, siehe Abschnitt „Ablauf“.
- Was passiert mit einem neuen Wunsch mitten im Sprint?
Er kommt nicht in den laufenden Sprint, sondern als neuer Eintrag ins Product Backlog; der Product Owner priorisiert ihn, und ab dem nächsten Sprint Planning kann er umgesetzt werden. Nur wenn das Sprintziel völlig überholt ist, darf der Product Owner den Sprint abbrechen, siehe Abschnitt „Stakeholder“.
- Was unterscheidet Sprint Review und Sprint Retrospective?
Im Sprint Review prüft das Scrum Team mit den Stakeholdern das Produkt (das Increment) und passt das Product Backlog an; in der Retrospective reflektiert das Scrum Team ohne Stakeholder seine Zusammenarbeit, Abläufe, Werkzeuge und die Definition of Done, siehe Abschnitt „Ablauf“.
- Was ist die Definition of Done, und warum ist sie für die Qualität wichtig?
Die Definition of Done legt gemeinsam vereinbarte Qualitätskriterien fest (z. B. getestet, Code-Review erfolgt, dokumentiert). Nur was sie erfüllt, gehört zum Increment; Testen wird damit Teil jedes Eintrags statt einer späteren Phase, siehe Abschnitt „Qualität und Test“.
- Was muss vor dem ersten Sprint vereinbart sein?
Die Verantwortlichkeiten müssen besetzt sein, ein erstes Product Backlog mit Produktziel muss vorliegen, Sprintlänge und Termine der Ereignisse müssen feststehen, die Definition of Done muss vereinbart, ein Board eingerichtet und technische Praktiken wie Versionsverwaltung und CI eingeführt sein, siehe Abschnitt „Ein agiles Projekt mit Scrum starten“.
- Welche häufig mit Scrum verbundenen Techniken stehen nicht im Scrum Guide?
Unter anderem User Stories, Story Points und Planning Poker, Task Boards, Burndown-Charts, Velocity und die Definition of Ready; sie sind nützlich, gehören aber nicht zum Kern von Scrum, siehe Abschnitt „Häufig genutzte Techniken“ und Abschnitt „Planung und Kontrolle“.
- Welche Missverständnisse über Scrum gibt es, und wann ist Scrum ungeeignet?
Häufig wird der Scrum Master für den Chef, das Daily für einen Statusbericht oder „agil“ für „ohne Dokumentation“ gehalten. Ungeeignet ist Scrum etwa bei feststehenden Anforderungen, sehr kleinen Vorhaben, fehlendem Personal für Product Owner oder Scrum Master, Festpreis mit festem Umfang oder stark hierarchischer Kultur, siehe Abschnitt „Risiken, Stärken und Grenzen“.
Links und weitere Informationen
Vorgehensmodelle: klassisch und agil (Überblick, Agiles Manifest, Vergleich)
als Nachschlagewerk: Der Scrum Guide (deutsche Fassung, November 2020)
für den Einstieg: Manifest für Agile Softwareentwicklung (deutsch)
historisch: Hirotaka Takeuchi, Ikujiro Nonaka: The New New Product Development Game. Harvard Business Review, Januar 1986
Hinweis zur Nachnutzung als Open Educational Resource (OER)
Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Scrum: das verbreitetste agile Rahmenwerk” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/scrum veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/vorgehensmodelle/vorgehensmodelle. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 30.10.2026.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
