Scrum verstehen und anwenden

Scrum ist ein agiles und empirisches Framework, das Teams hilft, komplexe Produkte iterativ und inkrementell zu entwickeln. Dieser Artikel erklärt Rollen, Events und Artefakte – praxisnah und verständlich.

Was ist Scrum?

Scrum ist wohl das berühmteste Rahmenwerk zur Lösung komplexer Probleme innerhalb des agilen Projektmanagement. Der Begriff "Scrum" stammt ursprünglich aus dem Rugby und beschreibt eine Formation, in der Spieler zusammenarbeiten, um den Ball stückweise zu bewegen.

Übersetzt in das Projektmanagement bedeutet es, ein Scrum Team arbeitet zusammen, um ein Ziel zu erreichen. Dabei liegt der Fokus auf Anpassung an Echtzeitbedingungen und kontinuierlicher Verbesserung, statt einem steifen Plan zu folgen. Große Ziele sollen in kleine handhabare Schritte unterteilt werden, um den Fokus nicht zu verlieren und Ziele pünktlich einzuhalten.

Weiterhin hilft Scrum, Teams durch iteratives Vorgehen und Feedbackschleifen wertvolle Produkte zu liefern und kann somit die agile Denkweise unterstützen.

Ziel: Produkte liefern, die wirklich gebraucht werden – nicht nur das, was im Lastenheft stand.

Scrum basiert zudem auf den Prinzipien Empirie (Wissen entsteht durch Erfahrung) und Lean Thinking (Wertefokus, Vermeidung von Verschwendung). Es definiert bewusst nur die notwendigen Rahmenbedingungen (keine Regeln), um Klarheit und Grenzen zu schaffen – der Rest wird vom Team gestaltet.

Wichtig: Scrum ist kein Prozess oder Tool – es ist ein Rahmenwerk, das Teams hilft, ihre Zusammenarbeit selbst zu gestalten.

Die 3 Säulen von Scrum

Traditionelle "Wasserfall" Projekte sind oft durch Zeit, Kosten und die Rahmenbedingungen eingeschränkt. Anpassungen sind in der Regel nicht möglich, da sie den gesamten Projektplan gefährden würden. Das Problem allerdings kann sein, dass sich innerhalb des Projektes die Rahmenbedingungen ändern und das Projekt nicht mehr den Anforderungen entspricht. Damit ist das Projekt zum Scheitern verurteilt.

Scrum hingegen ist ein empirisches und iteratives Vorgehen, das auf den Prinzipien der Transparenz, Überprüfung und Anpassung basiert.

• Transparenz (Transparency): Informationen über den Fortschritt und Zustand der Arbeit müssen jederzeit sichtbar sein.
• Überprüfung (Inspection): Scrum-Events dienen dazu, regelmäßig Ergebnisse und Prozesse zu prüfen.
• Anpassung (Adaptation): Neue Erkenntnisse führen zu gezielten Änderungen – sofort, nicht irgendwann.

Kosten und Zeit bleiben unverändert, aber die Rahmenbedingungen sind flexibel.

Die Scrum-Werte

Scrum basiert auf fünf zentralen Werten:

• Commitment – sich dem Sprint-Ziel und dem Team verpflichtet fühlen
• Focus – Fokus auf das Ziel des aktuellen Sprints
• Openness – Offenheit im Umgang mit Herausforderungen
• Respect – gegenseitiger Respekt für Fachlichkeit und Rolle
• Courage – den Mut, Probleme anzusprechen und Neues auszuprobieren

Der Gegenspieler wäre beispielsweise Multi-Tasking. Durch den ständigen Kontextwechsel wird schnell der Fokus verloren und die Effizienz leidet. Scrum Teams arbeiten zusammen und fokusieren sich gleichzeitig auf eine limitierte Anzahl an "wertvollen" Aufgaben.

Die Scrum-Rollen im Detail

Scrum aber auch die agile Denkweise kennt drei klar definierte Accountabilities – also Verantwortungsbereiche. Nur wenn alle Rollen ihren Beitrag leisten, funktioniert Scrum im Sinne der Empirie. Um die Rollen zu verstehen, ist es wichtig die agile Denkweise zu verinnerlichen. Die vorgesehenen Rollen grenzen sich klar von den klassischen Rollen, z.B. Projektmanager, ab. Zum Beispiel ist der Scrum Master nicht der Chef des Teams, sondern ein Coach, der das Team dabei unterstützt, die Scrum-Prinzipien zu leben und sich selbst zu organisieren. Der Product Owner wiederum arbeitet eng mit dem Team zusammen, statt nur Anforderungen zu delegieren.

Product Owner (PO)

Der Product Owner ist verantwortlich für den Wert des Produkts und der Produktvision, was aus der Arbeit des Teams entsteht. Er repräsentiert Vollzeit das Business und ist allein verantwortlich für das Product Backlog. Er setzt die Richtung fest und sorgt dafür, dass das Team an den "wertvollen" (priorisierten) Dingen arbeitet. Zudem überprüft er die Arbeit des Teams und stellt sicher, dass es den richtigen Fokus hat. Die Kommunikation findet auf einer täglichen Basis statt, mit dem Team als auch mit den Stakeholdern. Vermutlich deswegen ist der PO auch als die wichtigste Rolle im Scrum Team bekannt.

Hauptaufgaben:

• Produktziel (Product Goal) definieren und kommunizieren
• Product Backlog kontinuierlich pflegen: Einträge erstellen/entfernen, priorisieren, klar beschreiben
• Sicherstellen, dass das Backlog transparent und für alle verständlich ist (bsp. im Sprint ein Backlog Refinement Meeting)
• Entscheidungen treffen, die im Backlog sichtbar werden

Scrum Master (SM)

Die Verantwortung wird jedoch nicht alleine vom PO getragen, als Gegenspieler gibt es einen "Coach" – den Scrum Master. Er gleicht die Bedürfnisse des PO's und des Teams aus und sorgt für eine gleichbleibende Leistung und Transparenz im Prozess. Der Scrum Master ist zudem Verantwortlicher für die Anwendung von Scrum im Team und in der Organisation. Er dient als Vermittler und Hindernissen-Entferner, allerdings ist er nicht ein Manager. Seine Rolle ist flexibel und kann sich innerhalb des Teams ändern, je nach den Bedürfnissen des Teams und der Organisation. Anfänglich kann der Scrum Master ein Coach sein, der das Team bei der Einführung von Scrum unterstützt. Später kann er sich in eine unterstützende Rolle (Administration) zurückziehen, während das Team selbstorganisiert arbeitet.

Für das Team:

• Förderung von Selbstorganisation und Cross-Funktionalität
• Sicherstellen, dass alle Scrum-Events effektiv durchgeführt werden
• Unterstützung bei kontinuierlicher Verbesserung
• Schützt das Team vor äußeren Störungen und Hindernissen

Für den Product Owner:

• Unterstützung bei Produktvision und Backlogmanagement
• Förderung effektiver Stakeholder-Zusammenarbeit
• Vermittlung zwischen Geschäfts- und Entwicklungsperspektiven

Für die Organisation:

• Scrum-Einführung unterstützen und begleiten
• Training & Coaching von Teams und Führungskräften
• Hindernisse zwischen Teams und Stakeholdern beseitigen

Developers

Die Entwickler:innen im Scrum Team sind verantwortlich für die Erstellung des Produktinkrements. Sie organisieren sich selbst und sind gemeinsam für die Umsetzung des Sprint Goals zuständig.

Ihre Verantwortungen:

• Sprint Backlog erstellen und pflegen
• Einhaltung der Definition of Done
• Qualität sicherstellen
• Tägliche Abstimmung und Planung (z.B. Daily Scrum)
• Verantwortung für technische Umsetzung und Lieferung

Das Team aufsetzen

Empirische Studien haben gezeigt, dass die Teamgröße zwischen 5 und 9 Personen liegen sollte, um eine effektive Zusammenarbeit zu gewährleisten. Das bedeutet aber, dass mit dieser Teamgröße auch alle Kompetenzen abgedeckt werden müssen, um die Aufgaben zu erledigen. Das Team sollte folglich cross-funktional aufgestellt sein, um alle notwendigen Fähigkeiten zu vereinen.

Außerdem sollte das Team sich nur auf ein Produkt konzentrieren, um den Fokus zu behalten und Multitasking zu vermeiden. Multitasking führt zu Ineffizienz und erhöht die Wahrscheinlichkeit von Fehlern.

Die Kommunikation sollte auf einer täglichen Basis stattfinden. Stehen gemeinsame Arbeitsräume nicht zur Verfügung, können auch digitale Tools wie Slack, Microsoft Teams oder Zoom genutzt werden.

Wichtig dabei ist, sich auf eine gemeinsame Sprache und Normen zu einigen, um Missverständnisse zu vermeiden und eine gute Zusammenarbeit zu fördern.

Die Scrum-Events

Scrum strukturiert die Arbeit über fünf wiederkehrende Events:

Sprint

Der Sprint ist der Herzschlag von Scrum – ein fixer Zeitrahmen (meist 2 Wochen, max. 1 Monat), in dem ein wertvolles, potenziell auslieferbares Inkrement entsteht. Er enthält alle Entwicklungsschritte vom klassischen Waterfall-Prozess: Planung, Analyse, Design, Entwicklung, Test und Auslieferung nur in kleineren Zeitabschnitten und simultan.

Merkmale:

• Keine Änderungen, die das Sprint Goal gefährden
• Refinement kann im Sprint stattfinden
• Ergebnis: Fortschritt zum Product Goal

Sprint Planning

Das Sprint-Planning Meeting markiert den ersten Tag des Sprints und dient zur Planung des anstehenden Sprints. Der PO stellt die wichtigsten und wertvollsten Themen vor und das Team entscheidet, was in diesem Sprint umgesetzt werden kann. Es sollte weniger als 2 Stunden benötigen und diese drei Fragen beantworten:

1. Warum ist dieser Sprint wertvoll? (Sprint Goal)
2. Was kann in diesem Sprint erreicht werden? (Auswahl von Backlog Items)
3. Wie wird die Arbeit umgesetzt? (Planung durch das Entwicklungsteam und Aufwandschätzungen )

Alle Team Mitglieder, Scrum Master und PO müssen am Meeting teilnehmen. Am Ende steht das Commitment jedes Teammitglieds, das Sprint Goal zu erreichen und jedem sind die Aufgaben und die Verantwortlichkeiten klar.

Sprint Backlog = Sprint Goal + gewählte Product Backlog Items + Plan zur Umsetzung

Sprint Goal

Ein klares Ziel für den Sprint, das Fokus und Ausrichtung gibt. Es darf während des Sprints nicht verändert werden.

Beispiel:

Deep dive: Burndown Chart

Ein Burndown Chart visualisiert den verbleibenden Arbeitsaufwand über die Zeit.

• Y-Achse: verbleibende Tasks / Story Points
• X-Achse: Zeit (Sprints)

Hilft, Engpässe früh zu erkennen und Fortschritt sichtbar zu machen.

Daily Scrum

Ein kurzes, tägliches, zur gleichen Zeit 15-Minuten-Meeting (Standup Meeting), dass alle auch den PO und Scrum Master zusammen bringt.

Ziel:

• Fortschritt zum Sprint Goal prüfen
• Plan für den nächsten Arbeitstag anpassen

Struktur: frei wählbar – Hauptsache fokussiert, lösungsorientiert, selbstorganisiert.

Als bewährt hat sich die 3 Fragen-Methode, die jeder Entwickler beantwortet:

1. Was habe ich seit dem letzten Meeting gemacht?
2. Was werde ich bis zum nächsten Meeting machen?
3. Welche Hindernisse stehen mir im Weg?

Das Meeting pflegt Zusammenarbeit, Kommunikation und Rhythmus (3Cs) und sorgt für Transparenz und unterstützende Verantwortlichkeiten im Team.

Sprint Review

Am Ende des Sprints – kein reines „Demo-Meeting“, sondern kollaborative Arbeitsrunde, die sogar mit Stakeholdern stattfinden kann. Das Team präsentiert das Inkrement und die Arbeit, die im Sprint erledigt wurde. Die Demo erlaubt es dem PO die getane Arbeit den Stakeholdern zu präsentieren und Feedback zu erhalten. Das sichert die Transparenz und baut Vertrauen auf, da alle Stakeholder die Möglichkeit haben, das Inkrement zu sehen und Feedback zu geben. Stakeholder lernen zu dem, wer was macht und wie das Team arbeitet. Es bietet Raum, um die Arbeit (User stories) zu inspizieren und auch über nicht-fertige Inkremente zu sprechen. So kann neu priorisiert und zukünftige Sprints geplant werden.

Das Meeting sollte weniger als 2 Stunden dauern.

Ziel:

• Inkrement inspizieren
• Feedback von Stakeholdern einholen
• Product Backlog ggf. anpassen

Deep dive: Velocity Chart

Die Velocity zeigt, wie viel Arbeit ein Team in vergangenen Sprints erledigt hat.

Hilfreich für:

• Planung zukünftiger Sprints
• Abschätzung von Release-Zeitpunkten

Sprint Retrospektive

Letztes Event des Sprints – Rückblick und Verbesserungsplan für das Team. Der Fokus liegt auf dem Team und der Zusammenarbeit, nicht auf den Produkt. Der Scrum Master moderiert die Retrospektive und sorgt dafür, dass alle Teammitglieder ihre Meinungen und Ideen einbringen können. Der PO oder Stakeholder sollte nicht teilnehmen, um eine offene Diskussion zu ermöglichen.

Das Meeting dauert maximal 3 Stunden und sollte in einem geschützten Raum stattfinden, um eine offene Diskussion zu ermöglichen.

Ziel:

• Zusammenarbeit, Prozesse und Tools reflektieren
• Konkrete Verbesserungsmaßnahmen ableiten
• Qualität und Effektivität steigern

Eine einfache Methode ist die Start-Stop-Continue-Methode:

• Start: Was sollten wir anfangen zu tun - was sollten wir verbessern?
• Stop: Was sollten wir aufhören zu tun - was hat nicht gut funktioniert?
• Continue: Was sollten wir beibehalten - was hat gut funktioniert?

Die Scrum-Artefakte

Scrum nutzt drei zentrale Artefakte – jeweils mit einem Commitment:

Product Backlog

Ein dynamisches, priorisiertes Arbeitsverzeichnis für das Produkt.

Merkmale:

• Wird laufend verfeinert (Backlog Refinement, nutzt auch evntuell die Story Points zur Neuausrichtung)
• Verantwortlich: Product Owner
• Enthält das Product Goal als übergeordnetes Ziel

Product Goal

Das Product Goal oder auch die Produktvision ist das langfristige Ziel des Produkts. Es dient als Orientierung für das Team und die Stakeholder und beschreibt für alle verständlich den gewünschten Endzustand des Produkts. Die Richtung innerhalb der Produktvision wird auch durch das MVP (Minimum Viable Product) beschrieben. Das MVP ist die kleinste Version des Produkts, die den Kunden einen Mehrwert bietet und gleichzeitig die wichtigsten Funktionen enthält, um Feedback zu erhalten.

Beispiel:

Diese Vision kann nun in Themenblöcke (z.B. Datenmanagement, Backend) und dann in kleinere Funktionen (Record-Button) unterteilt werden (decomposition), die dann in den Sprints umgesetzt werden.

Deep dive: User Stories – Anforderungen aus Sicht des Nutzers

Themenblöcke als auch Funktionen können immer noch viel zu groß sein, um sie in einem Sprint umzusetzen. Für den Kunden bzw. die Personen, die das Produkt nutzen, sind diese Themenblöcke nicht relevant, für sie zählt die Interaktion und der Nutzen des Produktes. Das bedeutet jede Interaktion erzählt dem Team eine Geschichte wie das Produkt genutzt werden kann/sollte - und das ist die User Story.

Scrum schreibt keine bestimmte Form für Product Backlog Items vor – aber in der Praxis haben sich User Stories als besonders hilfreich bewährt. Somit ist meist der PO verantwortlich für die Erstellung und Pflege der User Stories im Product Backlog.

Warum eine User Story?

Eine User Story ist eine kurze, verständliche Beschreibung einer Anforderung aus Sicht des Nutzers.

Agile Teams sollten sich dabei an den INVEST-Kriterien orientieren:

• Independent (unabhängig) - kann unabhängig umgesetzt werden
• Negotiable (verhandelbar) - keine vertraglichen Verpflichtungen
• Valuable (wertvoll) - bringt dem Kunden einen Mehrwert
• Estimable (schätzbar) - Entwickler können den Aufwand schätzen
• Small (klein) - klein genug, um in einem Sprint umgesetzt zu werden
• Testable (testbar) - kann getestet werden

Sie fördert das gemeinsame Verständnis und soll die Diskussion über das „Warum“ hinter einer Funktion innerhalb des Teams anregen (nicht unbedingt jetzt aber vielleicht später im Projekt). Im Gegensatz zu klassischen Anforderungen, die oft sehr technisch formuliert sind und exakt beschreiben, was getan werden soll, stehen hier der Nutzer und der Nutzen im Vordergrund. Je nach Rolle und Verständnis werden vermutlich der Detailgrad und die Formulierung der User Stories variieren. Business Analysten als Product Owner werden höchstwahrscheinlich mehr Details einfließen lassen, um alle möglichen Eventualitäten abzufangen, als Entwickler, die die User Stories umsetzen. Wichtig ist, dass jede User Story ein explizites Akzeptanzkriterium hat, damit alle Beteiligten wissen, wann die User Story als "done" gilt.

Typische Struktur:

Beispiel:

Vorteile:

• Stellt den Kundennutzen in den Mittelpunkt
• Fördert kontextbasiertes Denken
• Unterstützt eine strukturierte Priorisierung

Pitfalls:

• Mehrere User Stories in einer: Stories sind nicht unabhängig von einander, wodurch die Aufwandsschätzung und Priorisierung erschwert wird.
• Unklare Werte: Der Nutzen für den Kunden muss klar und nachvollziehbar sein.
• Technische Anforderungen aus Lastenheft: User Stories sind nicht für technische Anforderungen geeignet, da sie den Fokus auf den Kunden verlieren.
• Zu viele Details: User Stories sind keine Spezifikationen, sondern sollen den Dialog fördern. Zu viele Details können den kreativen Prozess behindern.

Roadmap und Release Planning

Trotz all der Flexibilität ist es wichtig, eine Roadmap zu haben, um die langfristige Vision und Strategie des Produkts zu kommunizieren. Die Roadmap ist ein strategisches Dokument, das die geplanten Releases und Meilensteine des Produkts beschreibt. Der Release-Plan verbindet die Roadmap mit dem Sprints und gibt einen Überblick über die geplanten Releases und deren Inhalte. Er bietet zudem Einsicht in "wie" das Team die Aufgaben über mehrere Sprints hinweg umsetzt.

Der PO ist dafür verantwortlich, die Roadmap zu erstellen und regelmäßig zu aktualisieren.

Sprint Backlog

Enthält:

• Das Sprint Goal
• Die ausgewählten Product Backlog Items
• Den Plan zur Umsetzung (Tasks)

Verantwortlich: Entwickler:innen
Wird täglich angepasst (Selbstorganisation)

Inkrement

Ein funktionsfähiges Ergebnis am Ende des Sprints – „Done“ im Sinne der Definition of Done.

• Kann vor, während oder nach dem Review ausgeliefert werden
• Muss mit allen bisherigen Inkrementen kompatibel sein
• Mehrere Inkremente pro Sprint sind möglich

Definition of Done

Beschreibt den Zustand, wann ein Backlog Item wirklich fertig ist.

Typische Kriterien:

• Implementierung abgeschlossen
• Tests bestanden
• Dokumentation gepflegt
• Review erfolgt

Wie überprüfe ich den Scrum-Prozess?

So genannte "Information Radiators" sind visuelle Darstellungen, die den Fortschritt und den Status des Scrum-Prozesses zeigen (z.B Task-Board). Sie helfen jeden, Transparenz zu schaffen und den Scrum- bzw. Projektfortschritt zu überwachen.

Es wurden bereits ein paar wichtige Informationen genannt, wie:

• Produkt Roadmap und Vision
• Team Normen und Werte
• Team's Definition of Done
• Release-Plan
• Sprint Backlog und Burndown Chart
• Sprint Review Ergebnisse
• Sprint Retrospektive Ergebnisse

Es ist ziemlich egal welches Tool für die Informationen verwendet wird, wichtig ist, dass sie für alle sichtbar sind und regelmäßig aktualisiert werden.

Praxisbeispiel: Scrum bei Galvanytics

Galvanytics ist ein unser SaaS-Produkt für Battery-Data-Analytics.

Vor Scrum:

• lange Planungsphasen, kein Feedback
• fehlende Transparenz über den Fortschritt
• unklare Prioritäten und Ziele
• unklare Verantwortlichkeiten

Mit Scrum:

• kurze Sprints (2 Wochen)
• Dailies waren aufgrund der Teamgröße mit Werksstudenten nicht möglich
• Sprint Planning und Retrospektiven wurden eingeführt
• Product Backlog mit User Stories und Akzeptanzkriterien
• Sprint Reviews mit Stakeholdern zur Feedback-Einholung

Häufige Herausforderungen

• PO ohne Entscheidungskompetenz
• Daily Scrum = reines Reporting
• Scrum-but: "Wir machen Scrum, aber…"
• keine Transparenz im Scrum Prozess: z.B. kein Sprint Backlog, kein Burndown Chart

Merke: Scrum ist nur wirksam, wenn es vollständig angewendet wird – nicht als Puzzle mit fehlenden Teilen.

Fazit

Scrum ist kein Dogma – aber auch kein Wunschkonzert. Es funktioniert am besten, wenn die Prinzipien, Rollen, Events und Werte im Zusammenspiel gelebt werden.

Scrum bringt echten Mehrwert durch:

• Klare Strukturen für komplexe Arbeit
• Feedback- und Lernzyklen
• Transparenz und Teamverantwortung
• Kundenorientierung und nachhaltige Entwicklung

Footnotes

1. https://scrumguides.org/ ↩