Das Scrum-Framework einfach erklärt: Rollen, Events, Artefakte
Agiles Arbeiten ist längst in vielen Organisationen angekommen. Statt starrer Fünf-Jahres-Pläne setzen Teams auf kurze, fokussierte Iterationen mit schnellem Kundenfeedback. Das bekannteste Framework dafür ist Scrum. In diesem Beitrag erkläre ich dir ausführlich, wie Scrum funktioniert, warum es funktioniert und worauf es in der Praxis ankommt – alles auf Basis des aktuellen Scrum Guides von 2020.
Wichtig vorab: Agil heißt nicht „planlos". In Scrum wird sogar sehr viel geplant – nur in kürzeren Zeithorizonten als beim klassischen Wasserfall, und immer wieder neu anhand dessen, was das Team unterwegs lernt.
Was ist Scrum überhaupt?
Scrum ist ein Rahmenwerk (Framework), kein fertiger Prozess und keine Methode mit Schritt-für-Schritt-Anleitung. Es gibt dir bewusst nur ein leichtgewichtiges Gerüst aus Rollen, Terminen und Artefakten vor – wie du es konkret füllst, bleibt dir überlassen. Genau das macht Scrum so flexibel und gleichzeitig so anspruchsvoll.
Scrum eignet sich vor allem für komplexe Vorhaben, bei denen zu Beginn weder das genaue Ziel noch der Lösungsweg vollständig klar sind – typisch in der Software- und Produktentwicklung, aber auch in Marketing, Forschung oder Organisationsentwicklung.
Die Grundlage: Empirie
Scrum beruht auf empirischer Prozesssteuerung – also Wissen aus Erfahrung statt aus Vorab-Annahmen. Drei Säulen tragen das:
Transparenz: Der Arbeitsstand und die Hindernisse sind für alle sichtbar. Ohne Ehrlichkeit keine guten Entscheidungen.
Überprüfung (Inspektion): Regelmäßig wird geschaut, wo man steht – im Daily, im Review, in der Retro.
Anpassung (Adaption): Aus dem Gesehenen wird sofort gelernt und der Kurs korrigiert.
Kurz: sichtbar machen → draufschauen → nachjustieren. Dieser Dreiklang wiederholt sich in jedem Sprint.
Die 5 Scrum-Werte
Was Scrum im Alltag trägt, sind weniger die Regeln als die Werte, die das Team lebt: Commitment (Selbstverpflichtung aufs Ziel), Fokus (auf die Arbeit des Sprints), Offenheit (für Arbeit und Herausforderungen), Respekt (füreinander als fähige Menschen) und Mut (Probleme anzusprechen und das Richtige zu tun). Ohne diese Haltung wird Scrum schnell zur leeren Hülle aus Terminen.
Das Scrum-Team und seine 3 Verantwortlichkeiten
Scrum kennt ein Scrum-Team von in der Regel maximal 10 Personen – ohne Unterteams, ohne Hierarchie, gemeinsam verantwortlich für das Ergebnis. Darin gibt es drei Verantwortlichkeiten (im aktuellen Guide bewusst nicht mehr „Rollen" genannt):
Product Owner
Maximiert den Wert des Produkts und verantwortet das Product Backlog: Was wird als Nächstes gebaut – und in welcher Reihenfolge? Der Product Owner ist eine Person (kein Komitee), trifft die Priorisierungs-Entscheidungen und ist die Brücke zwischen Stakeholdern und Team.
Scrum Master
Sorgt dafür, dass Scrum verstanden und gelebt wird – eine dienende Führungsrolle. Der Scrum Master beseitigt Hindernisse, schützt das Team vor Störungen, coacht zu Selbstorganisation und hilft der Organisation, agiler zu werden. Wichtig: kein klassischer Projektleiter und kein Vorgesetzter, der Aufgaben verteilt.
Developers
Das selbstorganisierte, crossfunktionale Team, das das Increment tatsächlich baut. „Developers" meint dabei alle Umsetzer:innen – nicht nur Programmierer:innen, sondern z. B. auch Designer:innen oder Tester:innen. Sie entscheiden gemeinsam, wie die Arbeit erledigt wird.
Die 5 Events
Alle Events dienen der Transparenz und der regelmäßigen Überprüfung & Anpassung. Sie haben eine maximale Dauer (Timebox), dürfen aber kürzer sein.
1. Der Sprint
Der Container für alles andere: ein fester Zeitraum von 1 bis 4 Wochen, in dem ein nutzbares Increment entsteht. Die Sprint-Länge bleibt konstant. Kürzere Sprints (1–2 Wochen) bringen schnelleres Feedback, längere passen in komplexere Umfelder. Ein Sprint wird nicht verlängert – nur in Ausnahmefällen vom Product Owner abgebrochen, wenn das Sprint-Ziel hinfällig wird.
2. Sprint Planning
Zu Beginn des Sprints (max. 8 Std. bei einem Monat). Das Team klärt drei Fragen: Warum ist dieser Sprint wertvoll (Sprint-Ziel)? Was kann geliefert werden (Auswahl aus dem Product Backlog nach dem Pull-Prinzip)? Wie wird die Arbeit erledigt (erster Plan)? Ergebnis ist das Sprint Backlog.
3. Daily Scrum
15 Minuten täglich, gleiche Zeit, gleicher Ort. Die Developers synchronisieren sich auf das Sprint-Ziel, planen den Tag und machen Hindernisse sichtbar. Es ist ein Planungs-Meeting der Developers – kein Status-Bericht an den Chef.
4. Sprint Review
Am Sprintende (max. 4 Std. bei einem Monat): Das fertige Increment wird Stakeholdern gezeigt, gemeinsam wird über Fortschritt und nächste Schritte gesprochen, Feedback fließt zurück ins Product Backlog. Ein Arbeitstreffen, keine reine Präsentation.
5. Sprint Retrospective
Der Blick aufs Team selbst (max. 3 Std.): Was lief in der Zusammenarbeit, bei Prozessen und Werkzeugen gut, was nicht? Das Team beschließt konkrete Verbesserungen für den nächsten Sprint. Die Retro ist der Motor der kontinuierlichen Verbesserung – wer sie streicht, nimmt Scrum das Herz.
Die 3 Artefakte – jeweils mit Commitment
Seit dem Scrum Guide 2020 hat jedes Artefakt ein Commitment, das ihm Fokus und Messbarkeit gibt:
Product Backlog → Commitment Product Goal. Die einzige, priorisierte, nie ganz „fertige" Liste aller Produkt-Aufgaben; das Wichtigste steht oben. Das Product Goal ist das langfristige Ziel, auf das das Team hinarbeitet.
Sprint Backlog → Commitment Sprint-Ziel. Das Sprint-Ziel (Warum) plus die ausgewählten Backlog-Einträge (Was) plus der Plan (Wie). Es gehört den Developers und wird im Sprint laufend aktualisiert.
Increment → Commitment Definition of Done. Das fertige, nutzbare Ergebnis. Ein Increment ist nur dann wirklich „fertig", wenn es die Definition of Done erfüllt – sonst darf es nicht als erledigt gelten.
Product Backlog Refinement
Kein eigenes Event, aber eine laufende Aktivität: Das Team verfeinert kontinuierlich die oberen Backlog-Einträge – zerlegt große Brocken in kleinere, ergänzt Details und Akzeptanzkriterien und schätzt den Aufwand. So sind die nächsten Einträge stets „ready" fürs nächste Planning. Faustregel: rund 10 % der Team-Kapazität.
Schätzen und Velocity
Statt in Stunden schätzen viele Teams in relativen Story Points – oft per Planning Poker. Über mehrere Sprints zeigt sich die Velocity: wie viele Punkte das Team im Schnitt schafft. Sie hilft bei der Vorhersage, ist aber ein Team-internes Werkzeug – kein Maßstab, um Teams zu vergleichen oder unter Druck zu setzen.
Der Scrum-Zyklus auf einen Blick
Aus einer Produktvision entsteht das priorisierte Product Backlog. Im Sprint Planning zieht sich das Team Arbeit für das Sprint-Ziel. Im Sprint bauen die Developers das Increment, synchronisieren sich täglich im Daily, zeigen das Ergebnis im Review und verbessern ihre Zusammenarbeit in der Retrospektive. Danach beginnt sofort der nächste Sprint – ohne Pause dazwischen. So entsteht Schritt für Schritt ein wertvolles Produkt.
Häufige Missverständnisse
„Scrum heißt keine Doku/keine Planung." Falsch – es wird laufend geplant und dokumentiert, nur schlanker und just-in-time.
„Der Scrum Master ist der neue Projektleiter." Nein – er führt dienend, verteilt keine Aufgaben und ist kein Vorgesetzter.
„Daily = Status-Meeting für den Chef." Nein – es ist die Selbst-Synchronisation der Developers.
„Velocity zeigt, wie gut ein Team ist." Nein – sie dient nur der Vorhersage innerhalb eines Teams.
„Wir machen Scrum, lassen aber die Retro weg." Dann fehlt der Verbesserungsmotor – das ist „Scrum-but", kein Scrum.
Wann passt Scrum – und wann nicht?
Stark, wenn: die Anforderungen unklar sind oder sich ändern, das Team eigenverantwortlich arbeiten kann und enges Kundenfeedback möglich ist. Weniger geeignet, wenn: die Aufgabe simpel und vollständig planbar ist (dann reicht klassisch), bei reinem Fließbetrieb mit ständig eintrudelnden Tickets (dort glänzt Kanban), oder wenn Organisation und Kultur Selbstorganisation nicht zulassen.
Häufige Fragen zu Scrum
Ist Scrum dasselbe wie agil?
Nein. „Agil" ist die übergeordnete Denkweise (Agiles Manifest). Scrum ist ein konkretes Rahmenwerk, um agil zu arbeiten – Kanban ist ein anderes.
Wie lange dauert ein Sprint?
1 bis 4 Wochen, konstant. Zwei Wochen sind in der Praxis am verbreitetsten.
Scrum oder Kanban?
Scrum bei iterativer Produktentwicklung mit festen Sprints und Zielen; Kanban beim kontinuierlichen Fluss vieler einzelner Aufgaben. Viele Teams kombinieren beides („Scrumban").
Fazit
Scrum ist bewusst einfach zu verstehen, aber schwer zu meistern: Das Gerüst ist schnell erklärt, doch die Wirkung entsteht erst durch gelebte Werte, echte Selbstorganisation und konsequente Verbesserung. Fang klein an, halte dich an den Rahmen – und justiere über die Retros kontinuierlich nach.
Du willst Scrum nicht nur verstehen, sondern in deinem Team wirklich einführen und leben? Genau dabei unterstütze ich mit praxisnahen Trainings und Workshops.