MethodenDeep-Dive
Scrum: Sprints, Events und Artefakte erklärt
Inhalt dieses Artikels
- Woher Scrum kommt
- Wie Scrum funktioniert: Empirie, Säulen und Werte
- Die Verantwortlichkeiten im Scrum Team
- Die fünf Scrum-Events
- Die drei Scrum-Artefakte und ihre Verpflichtungen
- Ein Sprint im Alltag: zwei Wochen am Beispiel
- Scrum, agil und Kanban: die Abgrenzung
- Typische Fehler bei der Einführung von Scrum
- Grenzen von Scrum
Scrum ist ein Rahmenwerk, in dem ein Team in Sprints von höchstens einem Monat ein nutzbares Ergebnis liefert und dabei Plan und Arbeitsweise regelmäßig überprüft. Was genau dazugehört, legt der Scrum Guide 2020 fest: drei Verantwortlichkeiten, fünf Events, drei Artefakte und die Regeln, die sie verbinden.
Scrum gibt einen festen Takt und feste Verantwortlichkeiten vor. Wer beides nicht braucht, weil die Arbeit ungleichmäßig hereinkommt, ist mit einem flussbasierten Vorgehen besser bedient.
Woher Scrum kommt
Den Namen Scrum hat ein Aufsatz von 1986 geprägt. Hirotaka Takeuchi und Ikujiro Nonaka verglichen in der Harvard Business Review unter dem Titel „The New New Product Development Game“ erfolgreiche Entwicklungsteams mit einer Rugby-Mannschaft, die als Einheit über das Feld zieht, statt die Arbeit von Abteilung zu Abteilung weiterzureichen. Das Gedränge beim Rugby heißt Scrum.
Ken Schwaber und Jeff Sutherland griffen den Begriff auf, entwickelten Anfang der 1990er-Jahre ein Rahmenwerk und stellten es 1995 auf der Konferenz OOPSLA erstmals gemeinsam vor. Den ersten Scrum Guide veröffentlichten sie 2010. Gültig ist die Fassung vom November 2020: Sie ist knapper als die Vorgänger und enthält keine Bezüge mehr auf IT-Arbeit.
Wie Scrum funktioniert: Empirie, Säulen und Werte
Scrum beruht auf Empirie: Entscheidungen fallen auf Grundlage dessen, was ein Team beobachtet, nicht auf Grundlage eines Plans, der alles vorab festlegt. Dazu nennt der Scrum Guide Lean Thinking, also den Verzicht auf alles, was nicht zum Ergebnis beiträgt. Aus der Empirie folgen drei Säulen:
- Transparenz: Arbeit und Fortschritt sind für alle sichtbar, die daran arbeiten oder das Ergebnis bekommen. Ohne Transparenz führt jede Überprüfung in die Irre.
- Überprüfung: Das Team prüft Ergebnis und Fortschritt in festem Rhythmus. Dafür gibt es die fünf Events.
- Anpassung: Weicht etwas ab, ändert das Team Vorgehen oder Ergebnis so schnell wie möglich.
Dazu kommen fünf Werte. Laut Scrum Guide hängt der Erfolg von Scrum davon ab, wie gut die Beteiligten sie leben:
- Commitment: Das Team verpflichtet sich auf seine Ziele und unterstützt sich gegenseitig.
- Fokus: Die Arbeit des Sprints hat Vorrang. Wie du Fokus im Alltag schützen kannst, zeigt der Artikel über digitalen Minimalismus.
- Offenheit: Team und Stakeholder sprechen offen über die Arbeit und ihre Probleme.
- Respekt: Die Mitglieder respektieren einander als fähige, eigenständige Menschen.
- Mut: Das Team tut das Richtige und geht schwierige Probleme an.
Überprüfung ohne Anpassung nennt der Scrum Guide sinnlos — jedes Event soll etwas verändern.
Die Verantwortlichkeiten im Scrum Team
Ein Scrum Team besteht aus einem Product Owner, einem Scrum Master und Developers, laut Scrum Guide typischerweise zehn oder weniger Personen. Innerhalb des Teams gibt es keine Teilteams und keine Hierarchie; das Team entscheidet selbst, wer was wann und wie macht.
Product Owner: verantwortet den Wert des Produkts und führt den Product Backlog. Eine Person, kein Gremium.
Scrum Master: verantwortet, dass Scrum so eingeführt wird, wie der Guide es beschreibt, und die Wirksamkeit des Teams. Keine Projektleitung.
Developers: erstellen in jedem Sprint ein nutzbares Inkrement, planen den Sprint und halten die Definition of Done ein.
Der Scrum Guide spricht seit 2020 von Verantwortlichkeiten, nicht von Rollen. Gemeint ist, wofür jemand einsteht, nicht eine Stellenbezeichnung. Wie die drei zusammenspielen, erklärt der Überblick über die Scrum-Rollen.
Die fünf Scrum-Events
Scrum kennt fünf Events: den Sprint als Rahmen und darin Sprint Planning, Daily Scrum, Sprint Review und Sprint-Retrospektive. Jedes Event ist eine feste Gelegenheit, zu überprüfen und anzupassen, und jedes hat eine Zeitbox, also eine Obergrenze für die Dauer. Die Zeitboxen im Scrum Guide gelten für einen Sprint von einem Monat; bei kürzeren Sprints sind die Events in der Regel kürzer.
Der Sprint
Der Sprint ist ein Zeitabschnitt fester Länge von höchstens einem Monat und der Rahmen für alle anderen Events. Der nächste Sprint beginnt unmittelbar nach dem Ende des vorigen. Während des Sprints gelten vier Regeln: keine Änderung, die das Sprint-Ziel gefährdet; die Qualität sinkt nicht; der Product Backlog wird bei Bedarf verfeinert; der Umfang kann mit dem Product Owner neu ausgehandelt werden, wenn das Team mehr weiß.
Wird das Sprint-Ziel hinfällig, kann der Product Owner den Sprint abbrechen; nur er hat diese Befugnis. Der Guide nennt für die Länge nur die Obergrenze. Kürzere Sprints bringen mehr Lernschleifen und begrenzen das Risiko, als Faustregel für den Anfang gelten zwei Wochen.
Sprint Planning
Das Sprint Planning eröffnet den Sprint. Das ganze Scrum Team klärt dort drei Fragen: Warum ist dieser Sprint wertvoll? Was kann in diesem Sprint fertig werden? Wie wird die ausgewählte Arbeit erledigt? Aus der ersten Frage entsteht das Sprint-Ziel, das vor dem Ende des Plannings feststehen muss.
Was in den Sprint kommt, wählen die Developers im Gespräch mit dem Product Owner aus. Wie sie die Arbeit erledigen, entscheiden allein die Developers. Die Zeitbox liegt bei höchstens acht Stunden für einen Monatssprint; ein Zwei-Wochen-Sprint kommt als Faustregel mit der Hälfte aus.
Daily Scrum
Das Daily Scrum ist ein 15-minütiges Event für die Developers, jeden Arbeitstag zur selben Zeit am selben Ort. Zweck ist, den Fortschritt zum Sprint-Ziel zu prüfen und den Plan für den nächsten Arbeitstag anzupassen. Die Form wählen die Developers selbst: Die drei bekannten Fragen „Was habe ich gestern getan, was tue ich heute, was hindert mich?“ hat der Scrum Guide 2020 gestrichen.
Product Owner und Scrum Master nehmen als Developers teil, wenn sie selbst an Einträgen im Sprint Backlog arbeiten. Das Daily ist kein Statusbericht an den Scrum Master oder an eine Führungskraft. Wer berichtet, statt zu planen, verschenkt den Zweck.
Sprint Review
Im Sprint Review prüft das Scrum Team mit den wichtigsten Stakeholdern, was im Sprint entstanden ist und was sich im Umfeld geändert hat. Gemeinsam entscheiden sie, was als Nächstes kommt; der Product Backlog kann dabei angepasst werden. Der Scrum Guide nennt das Review ausdrücklich eine Arbeitssitzung und warnt davor, es auf eine Präsentation zu beschränken.
Die Zeitbox liegt bei höchstens vier Stunden für einen Monatssprint. Das Review ist keine Freigabe-Schranke: Ein Inkrement darf schon vor dem Ende des Sprints an die Stakeholder gehen.
Sprint-Retrospektive
Die Sprint-Retrospektive schließt den Sprint ab. Das Team prüft, wie der Sprint in Bezug auf Menschen, Zusammenarbeit, Abläufe, Werkzeuge und Definition of Done gelaufen ist, und plant, wie es Qualität und Wirksamkeit steigert. Die wirksamsten Verbesserungen setzt es so schnell wie möglich um, auf Wunsch schon als Eintrag im nächsten Sprint Backlog.
Die Zeitbox liegt bei höchstens drei Stunden für einen Monatssprint. Was eine Retrospektive im Kern ist, erklärt die Definition; wie du sie Schritt für Schritt leitest, zeigt die Anleitung Retrospektive moderieren.
Die drei Scrum-Artefakte und ihre Verpflichtungen
Scrum kennt drei Artefakte: Product Backlog, Sprint Backlog und Inkrement. Jedes enthält eine Verpflichtung, im Scrum Guide Commitment genannt, an der sich der Fortschritt messen lässt: das Produktziel, das Sprint-Ziel und die Definition of Done.
Product Backlog und Produktziel
Der Product Backlog ist die geordnete Liste dessen, was das Produkt verbessern soll, und die einzige Quelle für die Arbeit des Scrum Teams. Er ist nie fertig, sondern ändert sich mit dem, was das Team lernt. Einträge, die in einem Sprint fertig werden können, gelten als bereit für das Sprint Planning. Dorthin kommen sie durch Refinement, also durch Zerlegen und Präzisieren.
Die Verpflichtung des Product Backlogs ist das Produktziel: ein künftiger Zustand des Produkts, auf den das Team hinarbeitet. Ein Team verfolgt immer nur ein Produktziel und erfüllt oder verwirft es, bevor es das nächste angeht. Wie sich ein solches Ziel mit messbaren Ergebnissen verbinden lässt, zeigt die Methode OKR.
Sprint Backlog und Sprint-Ziel
Der Sprint Backlog besteht aus drei Teilen: dem Sprint-Ziel (warum), den ausgewählten Einträgen aus dem Product Backlog (was) und dem Plan der Developers, wie sie sie umsetzen (wie). Er ist der Plan der Developers für die Developers und wird während des Sprints laufend aktualisiert.
Das Sprint-Ziel ist das eine Ziel des Sprints und lässt Spielraum bei der genauen Arbeit. Stellt sich heraus, dass die Arbeit anders aussieht als gedacht, verhandeln die Developers den Umfang mit dem Product Owner neu, ohne das Ziel aufzugeben. Ein Sprint ohne Ziel ist eine Aufgabenliste mit Termin.
Inkrement und Definition of Done
Ein Inkrement ist ein konkreter Schritt zum Produktziel: geprüft, nutzbar und mit allen früheren Inkrementen verträglich. In einem Sprint können mehrere Inkremente entstehen. Die Verpflichtung dazu ist die Definition of Done, die formale Beschreibung, wann ein Eintrag die Qualitätsanforderungen des Produkts erfüllt. Erst in diesem Moment entsteht ein Inkrement.
Was die Definition of Done nicht erfüllt, darf weder ausgeliefert noch im Sprint Review gezeigt werden und geht zurück in den Product Backlog. Arbeiten mehrere Scrum Teams an einem Produkt, gilt für alle dieselbe Definition of Done.
Ein Sprint im Alltag: zwei Wochen am Beispiel
Ein Team baut ein Kundenportal weiter. Das Sprint-Ziel für die nächsten zwei Wochen lautet: „Kundinnen und Kunden können ihre Rechnungsadresse selbst ändern.“ So verteilen sich die Termine über den Sprint:
| Zeitpunkt | Termin | Ergebnis |
|---|---|---|
| Tag 1, vormittags | Sprint Planning, bis zu vier Stunden | Sprint-Ziel und Sprint Backlog |
| jeden Arbeitstag, gleiche Uhrzeit | Daily Scrum, 15 Minuten | angepasster Plan für den nächsten Arbeitstag |
| nach Bedarf, etwa einmal pro Woche | Refinement, ein bis zwei Stunden | Einträge für das nächste Planning sind klein und klar genug |
| Tag 10, vormittags | Sprint Review, bis zu zwei Stunden | Entscheidung, was als Nächstes kommt; angepasster Product Backlog |
| Tag 10, nachmittags | Sprint-Retrospektive, bis zu 90 Minuten | ein bis zwei Verbesserungen für den nächsten Sprint |
Die Dauern in der Tabelle sind Faustregeln für zwei Wochen: Der Scrum Guide nennt nur Obergrenzen für einen Monatssprint. Refinement ist laut Scrum Guide kein eigenes Event, sondern eine laufende Tätigkeit. Ob ein Team dafür einen festen Termin ansetzt, entscheidet es selbst.
Am dritten Tag stellt sich heraus, dass die Adressprüfung eine Schnittstelle braucht, die erst in vier Wochen bereitsteht. Die Developers verhandeln mit dem Product Owner neu: Die Adresse wird vorerst ohne automatische Prüfung gespeichert. Das Sprint-Ziel bleibt, der Umfang ändert sich.
Scrum, agil und Kanban: die Abgrenzung
Scrum ist ein agiles Rahmenwerk, aber nicht dasselbe wie agil. Der Begriff geht auf das Manifest für Agile Softwareentwicklung von 2001 zurück, das vier Werte und zwölf Prinzipien nennt, aber keine Termine, Rollen oder Artefakte. Scrum ist eine von mehreren Arten, diese Haltung in einen festen Ablauf zu übersetzen. Welche weiteren es gibt, zeigt die Übersicht der agilen Methoden.
Kanban setzt an einer anderen Stelle an: Es begrenzt die Menge gleichzeitiger Arbeit, statt die Zeit in Sprints zu teilen, und schreibt keine Rollen vor. Den Vergleich mit Tabelle findest du im Artikel über die Kanban-Methode. Faustregel: Scrum passt, wenn ein Team ein Produkt weiterentwickelt und für jeden Zyklus ein gemeinsames Ziel braucht. Kanban passt, wenn Arbeit ungleichmäßig hereinkommt, etwa im Support.
Scrum ist auch kein Projektmanagement. Der Scrum Guide beschreibt ein Team, das sich selbst managt, und kennt keine Projektleitung. Termine, Budgets und Verträge regelt er nicht.
Typische Fehler bei der Einführung von Scrum
Das Daily Scrum als Statusbericht. Wenn jede Person reihum erzählt, was sie gestern getan hat, und dabei zum Scrum Master oder zur Führungskraft schaut, wird aus der Planungsrunde eine Kontrolle. Der Scrum Guide sieht das Daily für die Developers vor, mit Blick auf das Sprint-Ziel. Die Gegenprobe: Endet das Daily mit einem angepassten Plan für den Tag?
Der Scrum Master als verdeckte Projektleitung. Laut Scrum Guide entscheidet das Team selbst, wer was wann und wie macht. Verteilt der Scrum Master Aufgaben, verfolgt Termine und berichtet nach oben, fehlt genau die Rolle, die das Team befähigen soll, sich selbst zu managen.
Sprints ohne Sprint-Ziel. Ein Sprint, der nur aus einer Liste von Tickets besteht, gibt keinen Maßstab: Fällt eine Aufgabe weg oder kommt etwas dazu, weiß niemand, was jetzt zählt. Das Sprint-Ziel muss laut Scrum Guide vor dem Ende des Sprint Planning feststehen.
Retrospektiven ohne Maßnahme. Eine Retrospektive, aus der keine Änderung hervorgeht, ist Überprüfung ohne Anpassung. Faustregel: lieber eine Verbesserung, die im nächsten Sprint wirklich umgesetzt wird, als fünf, die auf einer Liste stehen bleiben.
Grenzen von Scrum
Arbeit, die nicht planbar hereinkommt. Ein Team, das jeden Tag auf neue Anfragen reagieren muss, etwa im Support oder Betrieb, kann kaum ein Sprint-Ziel festlegen, das zwei Wochen hält. Für solche Teams passt ein Vorgehen ohne Sprints wie Kanban besser.
Mehrere Teams an einem Produkt. Der Scrum Guide beschreibt ein Team. Für mehrere Teams am selben Produkt verlangt er nur ein gemeinsames Produktziel, einen Product Backlog, einen Product Owner und dieselbe Definition of Done. Wie sich die Teams untereinander abstimmen, lässt er offen.
Schätzen und Messen. Story Points, Velocity und User Stories stehen nicht im Scrum Guide. Es sind Ergänzungen, die ein Team hinzufügen kann, keine Regeln von Scrum. Burn-down-Charts erwähnt der Guide nur als eine von mehreren Prognosepraktiken und betont, dass sie Empirie nicht ersetzen.
Hindernisse außerhalb des Teams. Liegen die Ursachen in der Organisation, etwa bei widersprüchlichen Prioritäten mehrerer Führungskräfte, reicht der Rahmen eines Teams nicht. Dann hilft eine Begleitung, die mehrere Teams und ihr Umfeld im Blick hat, etwa durch einen Agile Coach.
Fragen und Antworten
Was ist Scrum einfach erklärt?
Scrum ist ein Rahmenwerk für Teams: Die Arbeit läuft in Sprints von höchstens einem Monat, und am Ende jedes Sprints steht ein nutzbares Ergebnis. Ein Product Owner legt fest, was als Nächstes am wichtigsten ist, die Developers entscheiden, wie sie es umsetzen, und ein Scrum Master sorgt dafür, dass Scrum funktioniert. Feste Termine im Sprint sorgen dafür, dass das Team Ergebnis und Arbeitsweise regelmäßig überprüft.
Was sind die drei Säulen von Scrum?
Transparenz, Überprüfung und Anpassung. Transparenz heißt: Arbeit und Fortschritt sind für alle sichtbar, die daran arbeiten oder das Ergebnis bekommen. Überprüfung heißt: Das Team schaut regelmäßig auf Ergebnis und Fortschritt, dafür gibt es die Events. Anpassung heißt: Weicht etwas ab, ändert das Team sein Vorgehen so schnell wie möglich. Der Scrum Guide 2020 nennt Überprüfung ohne Anpassung ausdrücklich sinnlos.
Was sind die fünf Scrum-Werte?
Commitment, Fokus, Offenheit, Respekt und Mut. Das Team verpflichtet sich auf seine Ziele, konzentriert sich auf die Arbeit des Sprints, spricht offen über Arbeit und Probleme, respektiert einander als fähige Menschen und hat den Mut, schwierige Probleme anzugehen. Laut Scrum Guide hängt der Erfolg von Scrum davon ab, wie gut die Beteiligten diese Werte leben, nicht davon, wie korrekt sie die Termine abhalten.
Wie lange dauert ein Sprint?
Höchstens einen Monat. Der Scrum Guide legt nur diese Obergrenze fest, die genaue Länge wählt das Team und behält sie dann bei. Kürzere Sprints bringen mehr Lernschleifen und begrenzen das Risiko, weil Fehlentwicklungen früher auffallen. Als Faustregel für den Anfang gelten zwei Wochen: lang genug für ein sichtbares Ergebnis, kurz genug, damit das Sprint-Ziel bis zum Ende trägt.
Wie groß ist ein Scrum Team?
Laut Scrum Guide 2020 typischerweise zehn oder weniger Personen, einschließlich Product Owner und Scrum Master. Kleinere Teams kommunizieren nach der Erfahrung der Autoren besser und sind produktiver. Wird ein Team zu groß, soll es sich in mehrere Scrum Teams aufteilen, die am selben Produkt arbeiten und sich ein Produktziel, einen Product Backlog und einen Product Owner teilen.
Was ist der Unterschied zwischen Scrum und agil?
Agil ist eine Haltung, Scrum ein konkretes Rahmenwerk. Das Manifest für Agile Softwareentwicklung von 2001 nennt vier Werte und zwölf Prinzipien, aber keine Termine, Rollen oder Artefakte. Scrum übersetzt diese Haltung in einen festen Ablauf mit Sprints, drei Verantwortlichkeiten, fünf Events und drei Artefakten. Ein Team kann agil arbeiten, ohne Scrum zu nutzen, etwa mit Kanban.
Gibt es Story Points in Scrum?
Nein, nicht im Scrum Guide. Story Points, Velocity und User Stories kommen im Text des Scrum Guide 2020 nicht vor. Es sind Ergänzungen, die Teams hinzufügen können, aber keine Regeln von Scrum. Der Guide sagt nur, dass die Developers die Größe der Einträge im Product Backlog einschätzen, und überlässt ihnen, wie sie das tun.
Ist Scrum nur für Softwareentwicklung?
Nein. Scrum stammt aus der Softwareentwicklung, der Scrum Guide 2020 hat aber bewusst alle Bezüge auf IT-Arbeit entfernt. Mit „Developers“ meint er alle, die die Arbeit machen, ausdrücklich auch Forschende und Analysten. Scrum passt überall, wo ein Team an einem Produkt arbeitet, das sich schrittweise verbessern lässt, etwa an einem Kursangebot oder einer Kampagne.
Quellen
- Scrum Guide 2020 (abgerufen am 3. Oktober 2026)
- Der Scrum Guide 2020, deutsche Übersetzung (PDF) (abgerufen am 3. Oktober 2026)
- Manifest für Agile Softwareentwicklung (abgerufen am 3. Oktober 2026)
- Takeuchi, Nonaka: The New New Product Development Game, Harvard Business Review 1986 (abgerufen am 3. Oktober 2026)