Scrum - Agiles Framework einfach erklärt

Scrum ist das weltweit meistgenutzte agile Framework für die Entwicklung komplexer Produkte. Entwickelt in den frühen 1990er Jahren von Ken Schwaber und Jeff Sutherland, ermöglicht Scrum Teams, in iterativen Zyklen (Sprints) inkrementell Wert zu liefern und dabei kontinuierlich zu lernen und sich anzupassen.

Der Name "Scrum" stammt aus dem Rugby und beschreibt das gemeinsame Vorrücken eines Teams zum Ziel. Diese Metapher verdeutlicht den Kern von Scrum: Ein selbstorganisiertes Team arbeitet zusammen an einem gemeinsamen Ziel, passt sich kontinuierlich an Veränderungen an und liefert regelmäßig funktionierende Ergebnisse.

Die 3 Scrum-Rollen

Product Owner

Der Product Owner ist verantwortlich für die Maximierung des Wertes des Produkts und die Arbeit des Entwicklungsteams. Er:

• Verwaltet und priorisiert das Product Backlog
• Definiert und kommuniziert die Produktvision
• Ist die Schnittstelle zu Stakeholdern und Kunden
• Trifft Entscheidungen über Features und Priorisierungen
• Akzeptiert oder lehnt Arbeitsergebnisse ab

Wichtig: Der Product Owner ist eine einzelne Person, kein Komitee. Diese klare Verantwortlichkeit ist entscheidend für schnelle Entscheidungen.

Scrum Master

Der Scrum Master ist der Servant Leader des Teams und verantwortlich für die Einhaltung und Verbesserung des Scrum-Prozesses:

• Schützt das Team vor Störungen und Ablenkungen
• Entfernt Hindernisse (Impediments)
• Moderiert Scrum-Events
• Coacht das Team in agilen Praktiken
• Fördert kontinuierliche Verbesserung
• Hilft der Organisation, Scrum zu verstehen

Der Scrum Master ist kein Projektmanager oder Teamleiter im klassischen Sinne - er dient dem Team, statt es zu führen.

Entwicklungsteam (Developers)

Das Entwicklungsteam besteht aus Fachleuten, die am Ende jedes Sprints ein potenziell auslieferbares Produktinkrement erstellen:

• Selbstorganisiert: Das Team entscheidet selbst, wie es die Arbeit erledigt
• Cross-funktional: Alle notwendigen Fähigkeiten sind im Team vorhanden
• Keine Hierarchien oder Titel innerhalb des Teams
• Optimale Größe: 3-9 Personen (ohne Product Owner und Scrum Master)
• Gemeinsame Verantwortung für alle Arbeitsergebnisse

Die 5 Scrum-Events

1. Sprint

Der Sprint ist das Herzstück von Scrum - ein Zeitraum von maximal einem Monat (typischerweise 2 Wochen), in dem ein nutzbares, potenziell auslieferbares Produktinkrement erstellt wird.

• Feste Länge: Sprints haben immer die gleiche Dauer
• Unveränderliches Ziel: Das Sprint-Ziel wird während des Sprints nicht geändert
• Geschützter Rahmen: Keine Änderungen, die das Sprint-Ziel gefährden
• Qualität bleibt konstant: Die Definition of Done wird nicht verringert

2. Sprint Planning

Im Sprint Planning plant das gesamte Scrum-Team die Arbeit für den kommenden Sprint:

• Was: Welche Items aus dem Product Backlog werden im Sprint umgesetzt?
• Warum: Was ist das Sprint-Ziel?
• Wie: Wie wird die Arbeit erledigt?
• Dauer: Maximal 8 Stunden für einen Monatssprint

Das Ergebnis ist das Sprint Backlog mit einem klaren Sprint-Ziel.

3. Daily Scrum (Daily Standup)

Ein tägliches 15-minütiges Event für das Entwicklungsteam zur Synchronisation:

• Was habe ich gestern getan, um das Sprint-Ziel zu erreichen?
• Was werde ich heute tun, um das Sprint-Ziel zu erreichen?
• Gibt es Hindernisse, die mich oder das Team blockieren?

Das Daily Scrum ist kein Statusreport an den Scrum Master oder Product Owner, sondern ein Planungsevent des Teams.

4. Sprint Review

Am Ende des Sprints präsentiert das Team das fertige Inkrement den Stakeholdern:

• Demonstration der erledigten Arbeit
• Feedback von Stakeholdern einholen
• Anpassung des Product Backlogs basierend auf Feedback
• Diskussion über nächste Schritte
• Dauer: Maximal 4 Stunden für einen Monatssprint

Es ist ein informelles Meeting, keine formale Abnahme oder PowerPoint-Präsentation.

5. Sprint Retrospektive

Das Team reflektiert über den vergangenen Sprint und identifiziert Verbesserungsmöglichkeiten:

• Was lief gut? (Keep)
• Was lief nicht gut? (Drop/Improve)
• Welche konkreten Maßnahmen werden im nächsten Sprint umgesetzt?
• Dauer: Maximal 3 Stunden für einen Monatssprint

Die Retrospektive ist entscheidend für kontinuierliche Verbesserung (Kaizen) und sollte niemals übersprungen werden.

Die 3 Scrum-Artefakte

Product Backlog

Eine priorisierte Liste aller bekannten Anforderungen an das Produkt:

• Einzige Quelle für alle Anforderungen
• Ständig weiterentwickelt und verfeinert (Backlog Refinement)
• Höher priorisierte Items sind detaillierter ausgearbeitet
• Der Product Owner ist verantwortlich für Inhalt, Verfügbarkeit und Priorisierung

Sprint Backlog

Die Menge der für den Sprint ausgewählten Product Backlog Items plus einem Plan zur Umsetzung:

• Gehört dem Entwicklungsteam
• Enthält das Sprint-Ziel
• Wird während des Sprints bei Bedarf aktualisiert
• Visualisiert typischerweise auf einem Taskboard

Inkrement

Die Summe aller fertigen Product Backlog Items am Ende eines Sprints:

• Muss der Definition of Done entsprechen
• Muss nutzbar und potenziell auslieferbar sein
• Ergänzt alle vorherigen Inkremente
• Kann, muss aber nicht, am Sprint-Ende released werden

Definition of Done (DoD)

Die Definition of Done ist ein gemeinsames Verständnis darüber, wann Arbeit als "fertig" gilt:

• Code ist geschrieben und reviewt
• Unit-Tests sind geschrieben und bestanden
• Integrationstests sind bestanden
• Dokumentation ist aktualisiert
• Code ist in den Hauptzweig gemergt
• Feature ist auf Staging-Umgebung getestet

Eine klare DoD sorgt für Transparenz und verhindert, dass halbfertige Arbeit als "done" deklariert wird.

Scrum vs. Kanban

Aspekt	Scrum	Kanban
Rhythmus	Feste Sprints (1-4 Wochen)	Kontinuierlicher Fluss
Rollen	Product Owner, Scrum Master, Developers	Keine vordefinierten Rollen
Änderungen	Nur zwischen Sprints	Jederzeit möglich
Planung	Sprint Planning zu Sprint-Beginn	Just-in-Time, kontinuierlich
Steuerung	Velocity, Burndown Charts	WIP-Limits, Lead Time, Cycle Time
Ideal für	Produktentwicklung, klare Releases	Support, Wartung, kontinuierliche Arbeit

Viele Teams kombinieren beide Ansätze zu "Scrumban" - sie nutzen Sprints für Planung und Retrospektiven, aber ein Kanban-Board für die Visualisierung und WIP-Limits.

Häufige Fehler bei Scrum

• Scrum-But: "Wir machen Scrum, aber ohne Retrospektiven" - Teil-Implementierungen untergraben den Nutzen
• Mini-Wasserfall: Analyse, Entwicklung, Test als Phasen im Sprint statt echtem Cross-funktionalem Arbeiten
• Fehlende Stakeholder-Einbindung: Sprint Reviews ohne echtes Feedback
• Product Owner als Proxy: PO hat keine echte Entscheidungsbefugnis
• Kein fertiges Inkrement: Am Sprint-Ende ist nichts wirklich "done"
• Daily als Statusreport: Developers berichten dem Scrum Master statt sich untereinander zu synchronisieren

Scrum bei Elasticbrains

Bei Elasticbrains setzen wir Scrum als bewährtes Framework für unsere Entwicklungsprojekte ein:

• 2-Wochen-Sprints: Kurze Zyklen für schnelles Feedback und hohe Flexibilität
• Cross-funktionale Teams: Entwickler, Designer und QA arbeiten als einheitliches Team
• Transparente Kommunikation: Regelmäßige Sprint Reviews mit Kunden für frühzeitiges Feedback
• Kontinuierliche Verbesserung: Retrospektiven führen zu messbaren Prozessverbesserungen
• Kombination mit Kanban: Wir nutzen Kanban-Boards für visuelle Arbeitssteuerung
• DevOps-Integration: CI/CD ermöglicht Releases jederzeit während des Sprints

Unsere erfahrenen Scrum Master und Product Owner helfen auch bei der Einführung von Scrum in Kundenorganisationen.

Scrum-Zertifizierungen

Die bekanntesten Zertifizierungen für Scrum-Praktiker:

• Scrum.org: Professional Scrum Master (PSM I, II, III), Professional Scrum Product Owner (PSPO)
• Scrum Alliance: Certified ScrumMaster (CSM), Certified Scrum Product Owner (CSPO)
• SAFe: SAFe Scrum Master (SSM) für skalierte Umgebungen

Weiterführende Ressourcen

• Scrum Guide: Das offizielle Dokument von Schwaber und Sutherland (kostenlos auf scrumguides.org)
• Bücher: "Scrum: The Art of Doing Twice the Work in Half the Time" von Jeff Sutherland
• Tools: Jira, Azure DevOps, Trello, Monday.com für Scrum-Boards