Scrum Guide
Der umfassende Leitfaden zu Scrum: Events, Rollen, Artefakte und Best Practices
Die richtige Sprint-Länge in Scrum finden
Die Wahl der Sprint-Länge ist eine der ersten und wichtigsten Entscheidungen beim Start mit Scrum. Sie beeinflusst maßgeblich, wie schnell ihr Feedback bekommt und wie flexibel ihr auf Änderungen reagieren könnt.
Was sagt der Scrum Guide zur Sprint-Länge?
Der Scrum Guide definiert:
"Sprints sind das Herzstück von Scrum, in dem Ideen in Wert umgewandelt werden. Sie haben eine feste Länge von einem Monat oder weniger, um Konsistenz zu schaffen. Ein neuer Sprint beginnt unmittelbar nach dem Abschluss des vorherigen Sprints."
Das bedeutet: 1-4 Wochen sind möglich. Die konkrete Wahl überlässt Scrum bewusst dem Team.
Die drei häufigsten Sprint-Längen
1 Woche Sprints
Vorteile:
- •Maximale Flexibilität und schnelles Feedback
- •Kleine, überschaubare Arbeitspakete
- •Sehr hoher Fokus durch kurze Time-Box
Herausforderungen:
- •Hoher Planungs-Overhead (wöchentliche Events)
- •Schwierig bei komplexen Features mit Abhängigkeiten
- •Erfordert sehr gut vorbereitetes Backlog
2 Wochen Sprints (am häufigsten)
Vorteile:
- •Gute Balance zwischen Flexibilität und Planbarkeit
- •Genug Zeit für mittlere Features
- •Vertretbarer Event-Overhead
- •Industriestandard - einfacher Austausch mit anderen Teams
Empfehlung: Startet mit 2 Wochen, wenn ihr unsicher seid. Diese Länge funktioniert für die meisten Teams gut und ist ein solider Ausgangspunkt.
3-4 Wochen Sprints
Vorteile:
- •Zeit für komplexe Features mit vielen Abhängigkeiten
- •Weniger Planungs-Overhead
- •Gut bei Hardware-Entwicklung (lange Build-Zyklen)
Herausforderungen:
- •Langsames Feedback und geringere Flexibilität
- •Schwieriger, Fokus über längeren Zeitraum zu halten
- •Risiko von "Mini-Wasserfall" im Sprint
Faktoren für die Wahl der Sprint-Länge
Die optimale Sprint-Länge hängt von mehreren Faktoren ab:
🎯 Marktdynamik
Je schneller sich euer Markt verändert, desto kürzer sollten eure Sprints sein. Hohe Unsicherheit erfordert häufiges Inspect & Adapt.
🔧 Technische Komplexität
Lange Build-Zeiten, komplexe Deployment-Pipelines oder Hardware-Prototypen sprechen für längere Sprints (3-4 Wochen).
👥 Team-Reife
Neue Teams starten oft mit 2-3 Wochen. Erfahrene Teams können kürzere Sprints bewältigen, da Planung und Refinement gut eingespielt sind.
📦 Feature-Größe
Wenn ihr Features nicht klein genug schneiden könnt, braucht ihr längere Sprints. Besser ist aber: User Stories besser splitten lernen.
🔄 Feedback-Zyklen
Wie schnell braucht ihr Kundenfeedback? Je kritischer schnelles Lernen ist, desto kürzer sollten eure Sprints sein.
Häufige Fehler bei der Sprint-Länge
❌ Sprint-Länge ständig ändern
Der Scrum Guide betont: "Konsistenz schaffen". Ändert die Sprint-Länge nicht nach Belieben. Ein konstanter Rhythmus ist wichtiger als die "perfekte" Länge. Wenn überhaupt, dann passt die Länge nach der Sprint-Retrospektive an - und gebt der neuen Länge mindestens 3-4 Sprints, um sich einzuspielen.
❌ Sprint verlängern, um Features fertig zu bekommen
Wenn Features nicht fertig werden, ist das ein Lern-Signal! Verlängert nicht den Sprint, sondern schaut in der Retrospektive: Waren die Stories zu groß? War das Sprint-Ziel unklar? Gab es zu viele ungeplante Störungen?
❌ Zu lange Sprints aus Angst vor Overhead
"4-Wochen-Sprints, weil Planning und Review so aufwändig sind" ist ein Red Flag. Die Events sollten effizient sein. Wenn sie es nicht sind, liegt das Problem nicht bei der Sprint-Länge, sondern bei der Event-Facilitation.
Empirisch die richtige Länge finden
Scrum ist empirisch - das gilt auch für die Sprint-Länge:
- 1.Startet mit 2 Wochen
Ein solider Default für die meisten Teams.
- 2.Sammelt Daten über 3-4 Sprints
Beobachtet: Wie oft bleiben Features unfertig? Wie gut könnt ihr auf Änderungen reagieren? Fühlt sich der Rhythmus natürlich an?
- 3.Reflektiert in der Retrospektive
Diskutiert: Brauchen wir mehr/weniger Zeit? Oder müssen wir unsere Stories besser schneiden?
- 4.Experimentiert mit Änderungen
Wenn ihr etwas ändern wollt: Kündigt es an, probiert es für 3-4 Sprints, evaluiert dann erneut.
Scrum Master Zertifizierung
Lerne, wie du dein Team bei der Wahl der richtigen Sprint-Länge unterstützt und Scrum effektiv implementierst.
CSM Training anschauenSprint-Länge und Time-Boxing
Die feste Sprint-Länge ist ein Beispiel für Time-Boxing - eine der Kern-Praktiken in Scrum:
Time-Boxing bedeutet: Wir setzen eine feste Zeitgrenze und arbeiten darauf hin, innerhalb dieser Zeit möglichst viel Wert zu liefern.
Das Gegenteil wäre: "Wir arbeiten so lange, bis Feature X fertig ist" - das führt zu unkontrollierten Überstunden und fehlendem Fokus.
Time-Boxing schafft:
- Fokus: "Was ist das Wichtigste, das wir in dieser Zeit schaffen können?"
- Vorhersagbarkeit: Stakeholder wissen, wann sie mit Updates rechnen können
- Nachhaltiges Tempo: Keine "Crunch-Time" kurz vor imaginären Deadlines
- Regelmäßiges Inspect & Adapt: Feste Rhythmen für Feedback und Anpassung
Sprint-Länge in der Praxis
Beispiele aus der Praxis:
✅ Startup im E-Commerce (1 Woche)
"Wir sind in einem schnelllebigen Markt. Wöchentliche Sprints erlauben uns, auf Konkurrenz und Kundenfeedback sehr schnell zu reagieren. Unsere Stories sind klein und unser Backlog ist immer ready."
✅ Scale-Up SaaS-Produkt (2 Wochen)
"Unsere Features sind mittlerer Größe. 2 Wochen geben uns genug Zeit für Development, Testing und Review. Der Rhythmus passt perfekt zu unseren Release-Zyklen."
✅ Hardware-Entwicklung (4 Wochen)
"Wir entwickeln IoT-Geräte. Prototypen-Fertigung dauert 1-2 Wochen. Mit 4-Wochen-Sprints können wir Build-Test-Lern-Zyklen sinnvoll durchlaufen."
Häufig gestellte Fragen zur Sprint-Länge
Die Wahl hängt von mehreren Faktoren ab: Marktdynamik (je schneller der Markt, desto kürzer die Sprints), technische Komplexität (Hardware/lange Build-Zeiten → längere Sprints), Team-Reife (neue Teams: 2-3 Wochen, erfahrene Teams können kürzere Sprints bewältigen) und Feature-Größe. Der Industriestandard sind 2 Wochen - ein solider Ausgangspunkt für die meisten Teams, der eine gute Balance zwischen Flexibilität und Planbarkeit bietet.
Der Scrum Guide betont: Die Sprint-Länge soll "Konsistenz schaffen". Ein konstanter Rhythmus ist wichtiger als die vermeintlich "perfekte" Länge. Ständige Änderungen verhindern, dass das Team einen stabilen Arbeitsrhythmus findet und Vorhersagbarkeit entwickelt. Wenn überhaupt, dann passt die Länge nach der Sprint-Retrospektive an - und gebt der neuen Länge mindestens 3-4 Sprints, um sich einzuspielen, bevor ihr wieder evaluiert.
Nein, auf keinen Fall! Wenn Features nicht fertig werden, ist das ein wertvolles Lern-Signal, kein Problem, das durch Verlängern gelöst wird. Verlängert nicht den Sprint, sondern schaut in der Sprint-Retrospektive: Waren die User Stories zu groß geschnitten? War das Sprint-Ziel unklar formuliert? Gab es zu viele ungeplante Störungen? Die Sprint-Länge konstant zu halten zwingt das Team, die echten Ursachen zu identifizieren und zu beheben.
Scrum ist empirisch - das gilt auch für die Sprint-Länge. Der Prozess: (1) Startet mit 2 Wochen als solidem Default, (2) Sammelt Daten über 3-4 Sprints (Wie oft bleiben Features unfertig? Wie gut könnt ihr auf Änderungen reagieren? Fühlt sich der Rhythmus natürlich an?), (3) Reflektiert in der Retrospektive: Brauchen wir mehr/weniger Zeit? Oder müssen wir unsere Stories besser schneiden?, (4) Experimentiert mit Änderungen: Kündigt es an, probiert es für 3-4 Sprints, evaluiert dann erneut. Wiederholt diesen Inspect-&-Adapt-Zyklus.
Time-Boxing bedeutet: Wir setzen eine feste Zeitgrenze (z.B. 2 Wochen) und arbeiten darauf hin, innerhalb dieser Zeit möglichst viel Wert zu liefern. Das Gegenteil wäre: "Wir arbeiten so lange, bis Feature X fertig ist" - das führt zu unkontrollierten Überstunden und fehlendem Fokus. Time-Boxing schafft: Fokus ("Was ist das Wichtigste jetzt?"), Vorhersagbarkeit für Stakeholder, nachhaltiges Tempo (keine Crunch-Time) und regelmäßiges Inspect & Adapt durch feste Feedback-Rhythmen. Die feste Sprint-Länge ist das zentrale Time-Boxing-Element in Scrum.
Podcast-Episoden zur Sprint-Länge
#38: Die passende Sprintlänge finden
Die Standard-Sprintlänge passt selten. Lerne die 5 kontextabhängigen Faktoren für die optimale Entscheidung kennen und vermeide den häufigen Fehler, Dysfunktionen zu überspielen.
#3: Timebox & Sprint in Scrum – Fokus durch zeitliche Begrenzung
Timebox richtig verstehen: Warum der Sprint in Scrum eine Timebox ist, wie zeitliche Begrenzung Fokus schafft und du Timeboxing sofort nutzen kannst. Mit Pomodoro-Technik.
#15: Umgang mit ungeplanter Arbeit im Sprint – 3 Schritte zur Kontrolle
Über 40% ungeplante Arbeit im Sprint? Schritt-für-Schritt-Anleitung für systematische Transparenz – erfassen, analysieren, limitieren. Konkrete Methoden für stabile Arbeitsbedingungen.
Scrum-Training buchen
Lerne Scrum in der Praxis kennen. Unsere zertifizierten Trainings vermitteln dir das nötige Wissen, um Scrum erfolgreich in deinem Unternehmen einzuführen.
Zu den Trainings