Scrum ist das bekannteste agile Rahmenwerk und wird oft mit „agil“ gleichgesetzt. Das ist es nicht: Scrum ist eine konkrete Art, agil zu arbeiten, nicht das Agile selbst. Wer es einmal in seinen Grundzügen versteht, sieht schnell, wie wenig und wie viel zugleich dahintersteckt.
Der Begriff Scrum stammt ursprünglich aus dem Rugby und beschreibt dort das gemeinsame Gedränge, in dem eine Mannschaft den Ball zusammen nach vorn bringt. Genau dieses Bild trägt: Scrum ist ein agiles Rahmenwerk, in dem ein Team gemeinsam auf ein Ziel zuarbeitet. Scrum ist ein agiles Framework, das nur einen Rahmen setzt; vieles bleibt bewusst offen.
01 · HerkunftWoher Scrum kommt: Jeff Sutherland und Ken Schwaber
Entstanden ist Scrum in den 1990er-Jahren aus der Praxis der Softwareentwicklung heraus und wurde 1995 erstmals öffentlich vorgestellt. Beide Autoren gehören später zu den Unterzeichnern des agilen Manifests und spiegeln die Grundgedanken daraus bis heute im Scrum Guide, einem bewusst schlanken Dokument von wenigen Seiten. Das Scrum Framework passt damit auf kaum mehr als ein Dutzend Seiten.
02 · PrinzipScrum erklärt: Empirie in kurzen Schleifen
Scrum baut auf empirischer Prozesssteuerung. Scrum basiert damit auf Erfahrung statt auf Vorhersage. Bei komplexer Arbeit lässt sich nicht alles vorab durchplanen, weil zu Beginn zu vieles schlicht unbekannt ist. Statt einem großen Plan bis ins Detail zu folgen, arbeitet das Team deshalb in kurzen, festen Zyklen. Nach jedem Zyklus schaut es auf das Ergebnis und passt sein Vorgehen an. Der Scrum Prozess läuft also iterativ und inkrementell. Die Basis sind die drei Säulen der Empirie: Transparenz, Überprüfung und Anpassung.
Gerade in komplexen Umfeldern, in denen sich Anforderungen während der Arbeit noch verändern, spielt dieses Vorgehen seine Stärke aus, weil es Kurskorrekturen nicht als Störung behandelt, sondern fest einplant. Genau darin liegen die Vorteile von Scrum: Das Team bleibt flexibel, wenn neue Anforderungen auftauchen, und lernt kontinuierlich dazu, während es in einem geschützten Rahmen arbeiten kann. Für komplexe Produkte ist diese agile Arbeitsweise deshalb oft die effizientere Wahl, weil sie das Vorgehen flexibel hält, statt es einzufrieren.
03 · TeamDas Scrum Team: klar definierte Verantwortlichkeiten
Das Scrum Team umfasst drei Verantwortlichkeiten. Diese klar definierten Verantwortlichkeiten sind keine Hierarchie und auch keine bloße Aufteilung von Aufgaben, sondern eine Zuordnung differenzierter Verantwortung:
Sein Fokus liegt darauf, zu jedem Zeitpunkt die beste Entscheidung für den Wert des Produkts zu treffen, wirtschaftlich und am Nutzen orientiert. Dass der Product Owner dafür das Product Backlog ordnet, mit Stakeholdern spricht, den Markt und die Domäne kennt, folgt aus dieser Verantwortung.
Der Scrum Master prägt Selbstorganisation. Er sorgt dafür, dass das Team innerhalb klarer Leitplanken eigenverantwortlich arbeitet, und richtet den Blick auf Kommunikation und Prozesse: wie die Menschen zusammenarbeiten, womit sie arbeiten und wie sie besser werden können. Der Scrum Master löst nicht die Probleme des Teams, er befähigt das Team, sie selbst zu lösen. Er agiert als Lehrer, Problemlöser, Coach, Mentor, Facilitator und Change Agent.
Sie verantworten das Increment, und zwar so, dass es dem Qualitätsanspruch gerecht wird. Dahinter steckt mehr als Code: Zuverlässigkeit, Nutzbarkeit, Gestaltung, Design, technische Exzellenz, all das, was am Ende über „gut genug“ entscheidet.
Zusammen bilden sie ein interdisziplinäres selbstorganisiertes Team. Das Scrum-Team bringt als Ganzes alle Fähigkeiten mit, die es braucht, um das Produkt umzusetzen. Entscheidend ist das „als Ganzes“: Die Verantwortung liegt beim Team, nicht bei einzelnen Teammitgliedern. Kein Teammitglied arbeitet für sich allein, und die Zusammenarbeit im Team trägt das Ergebnis. Wie eng Developer, Scrum Master und Product Owner dabei zusammenarbeiten, entscheidet über die Qualität.
04 · EventsDie fünf Scrum Events
Scrum kennt fünf Events. Eines davon, der Sprint, umschließt die anderen vier. Diese Scrum Meetings sind keine Termine um ihrer selbst willen. Am besten versteht man sie über das Problem, das sie jeweils lösen:
der Rahmen, der alles zusammenhält, ein fester Zeitraum von maximal einem Monat, in dem ein nutzbares Increment entsteht. Der Sprint gibt der Arbeit ihren Takt und schützt das Team sich für einen bestimmten Zeitraum auf ein einzelnen Ziel zu fokussieren.
Sprint Planning schafft Fokus. Dieses Meeting klärt, was wir als Nächstes überhaupt erreichen wollen. Ohne diese gemeinsame Ausrichtung arbeitet jeder für sich, quer zueinander, und am Ende kommt kein stimmiges Ergebnis heraus.
Daily Scrum sorgt dafür, dass wir das Ziel gemeinsam erreichen, statt zu Einzelkämpfern zu werden. Das Daily Scrum ist der tägliche Moment, in dem klar wird: Ich kann mich auf die anderen verlassen, und sie können sich auf mich verlassen.
Sprint Review löst den vielleicht größten Schmerz: Stimmt unsere Annahme überhaupt? Ob das, was wir gebaut haben, wirklich trägt, erfahren wir in den meisten Fällen erst hier, im ehrlichen Abgleich mit den Stakeholdern.
Sprint Retrospective nimmt sich den Schmerz vor, der immer dann entsteht, wenn in der Zusammenarbeit etwas schiefläuft. Tun wir das nicht, wiederholen wir dieselben Fehler über Wochen, Monate und Jahre, bis Menschen frustriert sind, ausbrennen oder gehen.
05 · AblaufSo läuft ein Sprint ab
In der Praxis greifen diese Events ineinander. Zu Beginn zieht das Team im Sprint Planning die wichtigsten Aufgaben aus dem Product Backlog und formuliert daraus ein Sprint-Ziel. Was es sich vornimmt, landet im Sprint Backlog, der damit die Liste von Aufgaben für genau diesen einen Sprint bildet.
Während des Sprints trifft sich das Team täglich im Daily Scrum und inspiziert den Forschritt zum Sprintziel. Das Sprint Review zeigt das Ergebnis, und die Sprint Retrospective schaut als letztes Event im Sprint auf die Zusammenarbeit. Danach beginnt der nächste Sprint. Diese Schleife wiederholt sich, Sprint für Sprint, und sorgt für kontinuierliche Verbesserung.
06 · ArtefakteDie Artefakte in Scrum – am Einkauf erklärt
Die drei Artefakte versteht man am einfachsten am Bild eines Einkaufs:
der Einkaufszettel. Oben steht, was wir dringend brauchen, weiter unten das, was nett wäre, aber gerade nicht nötig ist. Der Product Owner priorisiert diese Liste laufend.
das, was wir bei diesem einen Einkauf definitiv mitnehmen.
Das aus den einzelnen Zutaten gekochte Gericht. Ob dies wirklich „fertig“ ist, entscheidet die Definition of Done: Sind die Zutaten nicht frisch oder nicht so wie abgesprochen, wird das Essen nicht lecker, und derjenige, der es essen muss, der Stakeholder, ist unzufrieden.
Jedes Artefakt hat zusätzlich ein Commitment, das ihm Richtung gibt: das Product Goal als übergeordnetes Ziel hinter dem Product Backlog, das Sprint Goal als Ziel des aktuellen Sprints und die Definition of Done, die für das Increment festlegt, wann etwas wirklich fertig ist.
07 · WerteDie oft vergessene Hälfte: die Werte
Verantwortlichkeiten, Events und Artefakte sind das Gerüst. Tragen tut es erst durch die fünf Scrum-Werte: Commitment, Fokus, Offenheit, Respekt und Mut.
Ohne sie bleibt Scrum ein leeres Gerüst. Erst wenn ein Team offen über Probleme spricht, den Mut hat, Unbequemes anzusprechen, und sich gemeinsam auf ein Ziel fokussiert, entfaltet der Rahmen seine Wirkung.
08 · AbgrenzungWas Scrum nicht ist
Scrum ist ein Framework und gibt einen Rahmen, keine Komplettanleitung. Es schreibt keine Story Points, keine Tools und keine konkrete Technik vor; das Wie bleibt bewusst offen und füllt jedes Team selbst. Genau hier liegt die häufigste Verwechslung: Viele Organisationen übernehmen die Events und Begriffe, aber nicht die empirische Haltung dahinter. Bei der Implementierung von Scrum kommt dann ein mechanisches Scrum heraus, das alle Events abhält und trotzdem nicht lernt.
Und es ist, um es noch einmal zu sagen, nicht gleichbedeutend mit „agil“: Scrum ist ein Weg, agil zu denken und zu handeln, einer von mehreren. Agile Methoden wie Scrum oder Kanban sind Werkzeuge, keine Weltanschauung, und die Methode Scrum ist nur eine agile Methode von vielen. Diese Schlankheit ist seine Stärke und zugleich der Grund, warum es ohne die passende Haltung schnell zur leeren Hülle wird.
Den Scrum Guide liest du an einem Abend. Die Haltung dahinter braucht länger.
In der Guided Agile Community übst du über drei Monate an deinen echten Fällen, was Scrum vom mechanischen Abhalten der Events unterscheidet. Begleitet, mit Feedback und Menschen, die denselben Weg gehen.
Gründer der Guided Agile Community (GAC), PSM III-zertifiziert und Dozent an der Universität Hildesheim. Stefan begleitet Praktiker:innen dabei, agiles Wissen iterativ und praxisnah im Berufsalltag zu verankern.
Mehr über Stefan auf LinkedIn