Was ist Scrum?
- Stephan Bellmann
- 31. Jan.
- 7 Min. Lesezeit
Scrum erklärt: Struktur, Prinzipien und Wirkungsweise eines agilen Frameworks für komplexe Projekte
Inhalt
Einordnung
Scrum ist ein leichtgewichtiges agiles Framework zur Bewältigung komplexer Aufgaben und zur Entwicklung von Produkten, insbesondere in dynamischen Umfeldern wie Softwareentwicklung, Produktentwicklung oder anderen Innovationsprojekten. Es hilft Teams und Organisationen, Wert zu erzeugen, indem sie iterativ und inkrementell arbeiten, flexibel auf Veränderungen reagieren und regelmäßig lernen.
Formal definiert der Scrum Guide Scrum als ein Framework, das Menschen, Teams und Organisationen dabei unterstützt, in komplexen Situationen adaptive Lösungen zu entwickeln und kontinuierlich zu verbessern.
Quellen: [1], [2]
🎤 Interview: "Scrum oder Kanban - Studienanalyse und Praxiseinordnung mit Felix Huschka" - Felix Huschka
Grundprinzipien & Theorie hinter Scrum
Empirische Prozesskontrolle
Scrum basiert auf der empirischen Prozesskontrolle. Das bedeutet, dass Entscheidungen nicht primär auf Prognosen, langfristigen Detailplänen oder Annahmen beruhen, sondern auf realen Erfahrungen, beobachtbaren Ergebnissen und regelmäßigem Feedback.
Dieses Prinzip ist besonders relevant in komplexen und unsicheren Umfeldern, in denen Anforderungen, Technologien oder Marktbedingungen nicht vollständig im Voraus bekannt oder stabil sind. Anstatt diese Unsicherheit „wegzuplanen“, akzeptiert Scrum sie bewusst und nutzt kurze Lernzyklen, um schrittweise bessere Entscheidungen zu treffen.
Die empirische Prozesskontrolle wird in Scrum durch drei untrennbar miteinander verbundene Säulen getragen.
Transparenz
Transparenz bedeutet, dass alle für den Prozess relevanten Aspekte sichtbar, verständlich und einheitlich interpretiert sind.
In Scrum wird Transparenz unter anderem geschaffen durch:
klar definierte Artefakte (Product Backlog, Sprint Backlog, Inkrement)
explizite Commitments (Product Goal, Sprint Goal, Definition of Done)
gemeinsame Begriffe, Regeln und Arbeitsweisen
Transparenz bedeutet dabei nicht nur, Informationen verfügbar zu machen, sondern sicherzustellen, dass alle Beteiligten dieselbe Vorstellung vom aktuellen Stand haben.
Nur wenn Fortschritt, Probleme oder Qualitätsdefizite offen sichtbar sind, können Überprüfung und Anpassung wirksam erfolgen. Ohne Transparenz verlieren Überprüfung
und Anpassung ihre Wirkung.
Überprüfung (Inspection)
Überprüfung beschreibt das regelmäßige, systematische Prüfen von Arbeitsergebnissen, Zielen und Vorgehensweisen.
In Scrum ist Überprüfung fest im Prozess verankert, unter anderem durch:
das Daily Scrum (Überprüfung des Fortschritts in Richtung Sprint-Ziel)
das Sprint Review (Überprüfung des Inkrements und des Produktfortschritts)
die Sprint Retrospektive (Überprüfung der Zusammenarbeit und der Prozesse)
Überprüfung ist dabei kein klassisches Kontrollinstrument, sondern ein Mittel zur gemeinsamen Orientierung und zur Förderung von Lernfähigkeit. Sie erfolgt bewusst in kurzen Abständen, um Abweichungen frühzeitig zu erkennen.
Zu häufige oder ungeplante Überprüfungen können kontraproduktiv sein. Scrum definiert daher klar strukturierte Events mit festen Timeboxes.
Anpassung (Adaptation)
Anpassung bedeutet, erkannte Abweichungen oder neue Erkenntnisse konsequent in Veränderungen zu überführen.
Wenn bei der Überprüfung festgestellt wird, dass:
ein Ziel nicht mehr sinnvoll ist
Annahmen nicht zutreffen
die Qualität nicht ausreicht oder
Prozesse nicht effektiv funktionieren
muss das System angepasst werden – so früh wie möglich, um größere Folgeschäden zu vermeiden.
In Scrum zeigt sich Anpassung beispielsweise durch:
Neupriorisierung des Product Backlogs
Anpassung des Sprint-Ziels
Veränderung der Arbeitsweise des Teams
konkrete Verbesserungsmaßnahmen aus der Retrospektive
Anpassung ist damit kein Ausnahmefall, sondern ein normaler und erwarteter Bestandteil des Arbeitens in Scrum.
Zusammenspiel der drei Säulen
Die drei Säulen wirken nicht isoliert, sondern als zusammenhängendes System:
Transparenz schafft die Grundlage für sinnvolle Überprüfung, die wiederum notwendige Anpassungen ermöglicht.
Fehlt eine dieser Säulen, verliert Scrum seine empirische Wirksamkeit. Fehlende Transparenz oder beschönigte Statusberichte führen beispielsweise dazu, dass Probleme zu spät erkannt werden – ein typisches Muster stark plangetriebener Ansätze.
Quellen: [1]
📝Studien-Artikel: Scrum oder Kanban - welche Methode in welchem Kontext?
Wie funktioniert Scrum? – Die Struktur
Scrum organisiert Arbeit in klar definierten Elementen: Rollen, Ereignisse (Events) und Artefakte. Gemeinsam schaffen sie einen strukturierten, aber flexiblen Rahmen.
Rollen im Scrum Team
Ein Scrum Team besteht aus drei klar abgegrenzten Verantwortlichkeiten:
Product Owner
Der Product Owner trägt die Verantwortung für den Wert des Produkts, der durch die Arbeit des Scrum Teams entsteht. Er priorisiert Anforderungen und Entscheidungen konsequent entlang des Nutzens für Kund:innen, Nutzer:innen und Stakeholder. Zentrales Arbeitsinstrument ist das Product Backlog, das er kontinuierlich pflegt, priorisiert und verfeinert. Dabei stellt der Product Owner sicher, dass die Einträge verständlich, transparent und für das Team umsetzbar sind. Er fungiert als Schnittstelle zwischen Stakeholdern und Entwicklungsteam und sorgt dafür, dass alle Beteiligten eine gemeinsame Vorstellung von Produktziel und Prioritäten haben.
Scrum Master
Der Scrum Master ist für die Wirksamkeit von Scrum verantwortlich. Er unterstützt das Scrum Team dabei, Scrum zu verstehen, korrekt anzuwenden und kontinuierlich weiterzuentwickeln. Dabei agiert er nicht als klassische Führungskraft, sondern als Coach und Servant Leader. Der Scrum Master hilft, Hindernisse zu identifizieren und zu beseitigen, moderiert Scrum-Events bei Bedarf und fördert eine Umgebung, in der Selbstorganisation und kontinuierliche Verbesserung möglich sind. Zusätzlich unterstützt er die Organisation dabei, Scrum sinnvoll einzusetzen und bestehende Strukturen weiterzuentwickeln.
Entwickler:innen / Developers
Die Entwickler:innen sind verantwortlich für die Umsetzung der Arbeit innerhalb eines Sprints und für die Erstellung eines qualitativ hochwertigen Inkrements. Sie organisieren sich selbst und entscheiden eigenverantwortlich, wie sie die Arbeit technisch und fachlich am besten umsetzen. Dazu gehören Planung, Umsetzung, Qualitätssicherung und kontinuierliche Abstimmung im Team. Developers tragen gemeinsam die Verantwortung für das Erreichen des Sprint-Ziels und passen ihre Arbeitsweise bei Bedarf an, um Fortschritt, Qualität und Transparenz sicherzustellen.
Das Scrum Team ist interdisziplinär, selbstorganisiert und arbeitet gemeinsam auf ein übergeordnetes Produktziel hin.
Quellen: [1]
Scrum-Ereignisse (Events)
Scrum definiert eine Reihe strukturierter Ereignisse, die regelmäßig stattfinden:
Sprint
Ein Sprint ist ein zeitlich begrenzter Arbeitsabschnitt (in der Regel 1–4 Wochen), innerhalb dessen ein wertvolles Produktinkrement erstellt wird. Alle Arbeiten – Planung, Umsetzung, Review und Retrospektive – finden innerhalb dieses Zeitrahmens statt.
Sprint Planning
Zu Beginn jedes Sprints planen alle im Team gemeinsam drei zentrale Fragestellungen, die dem Sprint Richtung, Fokus und Umsetzbarkeit geben:
Warum der Sprint wertvoll ist: Das Scrum Team formuliert ein klares Sprint-Ziel, das beschreibt, welchen Beitrag der Sprint zum übergeordneten Produktziel leistet. Dieses „Warum“ schafft Sinn, Orientierung und Entscheidungssicherheit während des Sprints.
Was umgesetzt wird: Auf Basis der Priorisierung des Product Backlogs wählt das Team diejenigen Backlog-Einträge aus, die es im Sprint realistisch umsetzen kann. Dabei wird nicht maximal geplant, sondern bewusst so viel Arbeit ausgewählt, wie zur Erreichung des Sprint-Ziels notwendig und machbar ist.
Wie die Arbeit erledigt werden soll: Die Entwickler:innen planen eigenverantwortlich, wie sie die ausgewählten Backlog-Einträge technisch und organisatorisch umsetzen. Daraus entsteht das Sprint Backlog als konkreter Umsetzungsplan für den Sprint.
Daily Scrum
Ein tägliches, kurzes Treffen (max. 15 Minuten), in dem sich die Entwickler:innen auf den aktuellen Stand der Arbeit synchronisieren und den Plan für den nächsten Arbeitstag abstimmen. Der Fokus liegt nicht auf einem klassischen Statusbericht, sondern auf dem gemeinsamen Fortschritt in Richtung Sprint-Ziel. Die Teammitglieder machen transparent, woran sie arbeiten, welche Abhängigkeiten bestehen und ob Hindernisse den Fortschritt gefährden. Auf dieser Basis passen sie ihren Arbeitsplan an, um Abweichungen frühzeitig zu erkennen und gegenzusteuern.
Sprint Review
Am Ende des Sprints präsentiert das Scrum Team im Sprint Review das entstandene Inkrement den relevanten Stakeholdern. Ziel ist es, gemeinsam zu überprüfen, welchen Fortschritt das Produkt gemacht hat und ob das Inkrement den aktuellen Erwartungen und Bedürfnissen entspricht. Stakeholder geben Feedback, stellen Fragen und bringen neue Erkenntnisse oder veränderte Rahmenbedingungen ein. Auf dieser Basis werden mögliche Anpassungen am Product Backlog diskutiert, etwa durch neue Anforderungen, veränderte Prioritäten oder das Verwerfen nicht mehr sinnvoller Annahmen. Das Sprint Review ist damit kein Abnahmetermin im klassischen Sinne, sondern ein kollaboratives Arbeitsmeeting zur gemeinsamen Produktsteuerung.
Sprint Retrospective
Nach jedem Sprint reflektiert das Scrum Team in der Sprint Retrospektive seine Zusammenarbeit, Arbeitsweisen und Rahmenbedingungen. Der Fokus liegt darauf zu verstehen, was im zurückliegenden Sprint gut funktioniert hat, wo Probleme oder Reibungsverluste aufgetreten sind und welche Ursachen dahinterliegen. Ziel ist es nicht, Schuldige zu suchen, sondern gemeinsam zu lernen und konkrete, umsetzbare Verbesserungsmaßnahmen abzuleiten. Diese Maßnahmen werden priorisiert und möglichst bereits im nächsten Sprint erprobt, sodass kontinuierliche Verbesserung systematisch im Arbeitsalltag verankert wird.
Typischer zeitlicher Ablauf eines Sprints (Beispiel)
Ein vereinfachtes Beispiel für einen zweiwöchigen Sprint verdeutlicht die zeitliche Einordnung der Scrum-Ereignisse:
Sprintbeginn
Sprint Planning (z. B. 2–4 Stunden)
Sprintlaufzeit
Umsetzung der geplanten Arbeit
tägliche Daily Scrums zur Synchronisation
Sprintende
Sprint Review
Sprint Retrospektive
Direkt anschließend
Start des nächsten Sprints mit erneutem Sprint Planning
Es gibt bewusst keine Lücke zwischen zwei Sprints. Planung, Umsetzung, Überprüfung und Verbesserung bilden einen kontinuierlichen Zyklus, der die empirische Arbeitsweise von Scrum unterstützt.
Quellen: [1]
Scrum-Artefakte
Artefakte schaffen Transparenz über Arbeit, Fortschritt und Ziele:
Product Backlog
Eine priorisierte Liste aller Anforderungen, Wünsche und Funktionen, die für das Produkt vorgesehen sind. Das Product Backlog stellt die zentrale Transparenzquelle über die zukünftige Produktentwicklung dar und bildet die Grundlage für Planung, Abstimmung und Entscheidungsfindung im Scrum Team. Es ist bewusst dynamisch angelegt und wird kontinuierlich angepasst, um neue Erkenntnisse, Feedback aus Reviews, veränderte Rahmenbedingungen oder strategische Entscheidungen abzubilden.
Sprint Backlog
Beinhaltet die ausgewählten Einträge aus dem Product Backlog für den aktuellen Sprint sowie einen gemeinsamen Plan der Entwickler:innen, wie diese Arbeit innerhalb des Sprints umgesetzt wird. Typischerweise liegen diese Backlog-Einträge in Form von User Stories vor, also kurzen, nutzerzentrierten Beschreibungen von Anforderungen, die den gewünschten Nutzen in den Vordergrund stellen. User Stories sind jedoch kein verpflichtendes Format: Je nach Kontext können Backlog-Einträge auch als technische Aufgaben, Fehler (Bugs), Spikes zur Klärung von Unsicherheiten, Enabler oder nicht‑funktionale Anforderungen (z. B. Performance, Sicherheit) formuliert sein. Entscheidend ist nicht die Form, sondern dass die Einträge verständlich, priorisiert und geeignet sind, das Sprint‑Ziel zu unterstützen. Das Sprint Backlog macht transparent, welche Arbeiten notwendig sind, um dieses Ziel zu erreichen, und wie das Team seine Aufgaben koordiniert. Es wird während des Sprints kontinuierlich aktualisiert und angepasst, wenn neue Erkenntnisse entstehen oder sich der beste Weg zur Zielerreichung verändert.
Inkrement
Das Ergebnis eines Sprints – ein fertiges, integriertes und potenziell auslieferbares Produktteil, das den gemeinsam festgelegten Kriterien der Definition of Done entspricht. Ein Inkrement stellt dabei keinen bloßen Arbeitsfortschritt oder Zwischenstand dar, sondern einen überprüfbaren Mehrwert für das Produkt. Es muss nutzbar, qualitativ abgesichert und mit bestehenden Produktbestandteilen kompatibel sein, sodass es jederzeit ausgeliefert oder weiterverwendet werden könnte.
Zusätzlich definiert Scrum sogenannte Commitments, die jedem Artefakt zugeordnet sind und dessen Zweck sowie Fokus schärfen. Das Product Goal gibt dem Product Backlog eine langfristige Ausrichtung, das Sprint Goal fokussiert das Sprint Backlog auf ein gemeinsames Ziel für den Sprint, und die Definition of Done stellt sicher, dass jedes Inkrement ein einheitliches Qualitätsniveau erfüllt. Commitments sorgen damit für Klarheit, Verbindlichkeit und gemeinsame Erwartungen innerhalb des Scrum Teams.
Quellen: [1]
Fazit
Scrum ist kein detailliertes Projektmanagement-Handbuch, sondern ein bewusst schlankes Rahmenwerk, das Teams dabei unterstützt, komplexe Probleme adaptiv und wertorientiert zu lösen. Durch klare Rollen, feste Ereignisse und transparente Artefakte werden Prozesse lernbar, steuerbar und kontinuierlich verbesserbar gemacht. Die Kombination aus Empirie, Lean-Denken und iterativer Arbeitsweise macht Scrum besonders geeignet für dynamische und unsichere Projektumfelder.
Quellenverzeichnis
[1] Schwaber, K.; Sutherland, J. (2020): Der Scrum Guide – Der gültige Leitfaden für Scrum. Deutsche Version, scrumguides.org. Link
[2] Projektmagazin (o. J.): Scrum-Methode – Etappen, Tools und Rollen. projektmagazin.de. Link
Kommentare