Beiträge

Sprintlänge: Sollten Ihre Sprints 1, 2, 3 oder 4 Wochen dauern?

Ein agiles Team-Arbeitsumfeld mit einem Whiteboard-Kalender, auf dem Sprint-Blöcke in verschiedenen Farben für unterschiedliche Sprint-Längen markiert sind

Matt Lewandowski

Zuletzt aktualisiert am 16/02/20269 Min. Lesezeit

Die Wahl einer Sprintlänge wirkt wie eine kleine Entscheidung, bis Sie feststellen, dass sie prägt, wie Ihr Team plant, schätzt, reflektiert und liefert. Jede Scrum-Zeremonie skaliert mit der Sprintlänge, was bedeutet, dass Ihre Wahl Auswirkungen auf den gesamten Entwicklungsprozess hat. Die meisten Teams entscheiden sich standardmäßig für zwei Wochen, ohne darüber nachzudenken. Das funktioniert für viele, ist aber nicht die einzige Option und nicht immer die beste. Hier erfahren Sie, wie Sie die Sprintlänge wählen, die tatsächlich zu Ihrem Team passt.

Was der Scrum Guide sagt

Der Scrum Guide setzt eine Regel: Sprints sind einen Monat oder weniger. Das ist alles. Keine Mindestlänge, keine empfohlene Standardeinstellung, nur eine Obergrenze. In der Praxis hat die Industrie sich auf zwei-wöchige Sprints geeinigt. Etwa 58% der Teams nutzen sie, laut dem State of Agile Report. Aber diese Popularität macht sie nicht universell richtig. Ein-Wochen- und vier-Wochen-Sprints haben jeweils legitime Anwendungsfälle, und drei-Wochen-Sprints funktionieren leise gut für bestimmte Team-Strukturen.

58%

der Teams führen 2-Wochen-Sprints durch

4 weeks

maximale Sprintlänge gemäß Scrum Guide

~20%

der Sprint-Zeit üblicherweise durch Overhead verloren

Vergleich von Sprintlängen

Jede Sprintlänge schafft eine andere Balance zwischen Feedback-Geschwindigkeit und Ausführungszeit. So schneiden sie ab.

1-Wochen-Sprints

Aspekt	Detail
Best für	Startups, dringende Projekte, Teams mit sich schnell ändernden Anforderungen
Feedback-Geschwindigkeit	Sehr schnell, Sie lernen jede Woche etwas Neues
Zeremonie-Overhead	Hoch, etwa 20-25% des Sprints sind Meetings
Planungsaufwand	Niedrig pro Sprint, aber Sie planen vier Mal im Monat
Risiko	Niedrig, nur eine Woche Arbeit steht auf dem Spiel, wenn sich Prioritäten verschieben

Ein-Wochen-Sprints erzwingen extreme Priorisierung. Sie können nur eine Handvoll Elemente unterbringen, was bedeutet, dass das Team unerbittlich sein muss, was am wichtigsten ist. Sprint-Planung ist kurz (maximal zwei Stunden), aber sie findet jede einzelne Woche statt. Dieser Rhythmus funktioniert, wenn sich Anforderungen häufig ändern, wenn Sie sich im Produkt-Markt-Fit befinden oder wenn das Team enge Feedback-Schleifen benötigt, um mit den Stakeholdern abgestimmt zu bleiben. Er funktioniert nicht, wenn Arbeitsaufträge von Natur aus groß sind oder wenn das Team mehr Zeit in Zeremonien als beim Bauen verbringt.

2-Wochen-Sprints

Aspekt	Detail
Best für	Die meisten Teams, der Industrie-Standard aus gutem Grund
Feedback-Geschwindigkeit	Ausgewogen, schnell genug für die meisten Stakeholder-Anforderungen
Zeremonie-Overhead	Moderat, etwa 12-15% des Sprints sind Meetings
Planungsaufwand	Handhabbar, zweimal im Monat
Risiko	Niedrig bis moderat, zwei Wochen Arbeit steht auf dem Spiel

Zwei-Wochen-Sprints treffen den sweet spot für die meisten Organisationen. Es gibt genug Zeit, um sinnvolle Arbeit zu erledigen, aber der Feedback-Zyklus ist immer noch kurz genug, um Probleme früh zu erkennen. Backlog-Verfeinerung findet ein- oder zweimal pro Sprint statt, und das Team hat Zeit, neue Informationen zwischen Zeremonien zu verdauen. Dies ist aus gutem Grund der Standard. Wenn Sie unsicher sind, wo Sie anfangen sollen, fangen Sie hier an.

3-Wochen-Sprints

Aspekt	Detail
Best für	Teams mit schweren Abhängigkeiten oder komplexen Integrationsarbeiten
Feedback-Geschwindigkeit	Langsamer, aber ausreichend für stabile Produkte
Zeremonie-Overhead	Niedriger, etwa 10-12% des Sprints sind Meetings
Planungsaufwand	Weniger häufig, aber Sitzungen sind länger
Risiko	Moderat, drei Wochen Arbeit könnten daneben gehen

Drei-Wochen-Sprints sind ungewöhnlich, was einige Teams dazu bringt, sie zu vermeiden. Aber sie lösen ein echtes Problem: Wenn zwei Wochen nicht ganz ausreichen, um sinnvolle Features abzuschließen und zu integrieren, aber vier Wochen zu viel Abweichung vom Stakeholder-Feedback schaffen. Teams mit komplexen Abhängigkeiten über mehrere Services oder Teams hinweg landen hier auf natürliche Weise. Die zusätzliche Woche gibt Atempausen für Integration und Tests, ohne die Planungshorizonte zu weit auszudehnen.

4-Wochen-Sprints

Aspekt	Detail
Best für	Reife Teams mit stabilen Produkten und vorhersehbarer Arbeit
Feedback-Geschwindigkeit	Langsam, ein ganzer Monat zwischen Stakeholder-Check-ins
Zeremonie-Overhead	Niedrigste Prozentquote, etwa 8-10% des Sprints
Planungsaufwand	Einmal im Monat, aber Planungssitzungen sind länger (bis zu 8 Stunden)
Risiko	Höher, ein ganzer Monat Arbeit könnte überarbeitet werden müssen

Vier-Wochen-Sprints minimieren Zeremonie-Overhead als Prozentanteil der Gesamtzeit. Das Team bekommt mehr ungestörte Build-Zeit, aber der Feedback-Loop ist länger. Wenn das Team in die falsche Richtung geht, dauert es einen Monat, um die Richtung zu korrigieren. Dies funktioniert am besten für reife Teams, die stabile Produkte aufbauen, wo sich Anforderungen nicht häufig ändern. Es funktioniert nicht, wenn Stakeholder regelmäßige Sichtbarkeit benötigen oder wenn der Markt schneller ist als Ihr Sprint-Zyklus.

Ein Team, das in einem Konferenzraum zusammenarbeitet, mit einem Bildschirm, der ein Balkendiagramm zeigt, das Zeremonie-Overhead über verschiedene Sprint-Längen hinweg vergleicht

Die Zeremonie-Overhead-Berechnung

Hier ist eine Frage, die sich die meisten Teams nie stellen: Wie viel Prozent Ihres Sprints wird tatsächlich in Meetings verbracht? Scrum schreibt fünf Events vor, jeweils mit Zeitlimits, die mit der Sprintlänge skalieren. Lassen Sie uns den Zeremonie-Overhead für ein siebenköpfiges Team berechnen, das 40-Stunden-Wochen arbeitet.

Zeremonie	1-Wochen-Sprint	2-Wochen-Sprint	3-Wochen-Sprint	4-Wochen-Sprint
Sprint-Planung	2 Std	4 Std	6 Std	8 Std
Daily Standup	1,25 Std	2,5 Std	3,75 Std	5 Std
Sprint-Review	1 Std	2 Std	3 Std	4 Std
Retrospective	0,75 Std	1,5 Std	2,25 Std	3 Std
Verfeinerung	2 Std	4 Std	6 Std	8 Std
Zeremonie-Stunden insgesamt	7 Std	14 Std	21 Std	28 Std
Verfügbare Stunden	40 Std	80 Std	120 Std	160 Std
Overhead %	17,5%	17,5%	17,5%	17,5%

Die Prozentsätze sind ungefähr gleich, wenn Sie die proportionalen Zeitlimits des Scrum Guide befolgen. Aber hier ist, was die Mathematik nicht zeigt: Kontextwechsel-Kosten. Kürzere Sprints bedeuten häufigere Übergänge zwischen "Zeremonie-Modus" und "Build-Modus". Teams in Ein-Wochen-Sprints berichten oft, dass der Overhead sich viel höher anfühlt, als die Zahlen vermuten lassen, da die Zeremonien dicht beieinander liegen. In der Praxis skalieren viele Teams, die Ein-Wochen-Sprints führen, ihre Zeremonien nicht proportional herunter. Eine Retrospektive, die in einem zwei-Wochen-Sprint 90 Minuten dauert, dauert selten 45 Minuten in einem Ein-Wochen-Sprint. Dort erscheint der echte Overhead-Unterschied.

Optimieren Sie Zeremonien nicht auf Null

Einige Teams versuchen, den Overhead zu reduzieren, indem sie Zeremonien überspringen. Das geht nach hinten los. Das Überspringen von Retrospektiven bedeutet, dass sich Prozessprobleme verschärfen. Das Überspringen von Verfeinerung bedeutet, dass die Sprint-Planung dreimal so lange dauert. Die Zeremonien existieren aus einem Grund.

Entscheidungsfaktoren

Die Wahl einer Sprintlänge ist nicht nur Mathematik. Dies sind die Faktoren, die tatsächlich zählen.

Team-Reife

Neue Agile-Teams profitieren von kürzeren Sprints, da sie mehr Übung mit den Zeremonien bekommen. Erfahrene Teams können längere Sprints bewältigen, da sie die Disziplin verinnerlicht haben.

Release-Rhythmus

Wenn Sie kontinuierlich freigeben, ist die Sprintlänge weniger an die Bereitstellung gebunden. Wenn Freigaben an Sprint-Grenzen stattfinden, bedeuten kürzere Sprints häufigere Freigaben und schnelleres Benutzerfeedback.

Stakeholder-Anforderungen

Einige Stakeholder benötigen wöchentliche Sichtbarkeit. Andere sind mit monatlichen Check-ins zufrieden. Ihre Sprintlänge sollte der Feedback-Häufigkeit entsprechen, die Ihre Organisation benötigt.

Anforderungs-Volatilität

Wenn sich Anforderungen häufig ändern, reduzieren kürzere Sprints verschwendete Arbeit. Wenn Anforderungen stabil sind, ermöglichen längere Sprints dem Team, sich auf die Arbeit zu konzentrieren, ohne ständig neu zu planen.

Andere zu berücksichtigende Faktoren

Größe von Arbeitsaufträgen. Wenn die meisten User Stories 3-5 Tage dauern, lassen Ein-Wochen-Sprints fast keinen Raum für Fehler. Zwei oder drei-Wochen-Sprints bieten mehr Flexibilität. Verwenden Sie Planning Poker während Verfeinerung, um Aufträge zu schätzen und zu sehen, wie sie in verschiedene Sprintlängen passen. Team-Größe. Größere Teams (7-9 Personen) erzeugen mehr Koordinations-Overhead. Längere Sprints können diese Kosten besser absorbieren. Kleinere Teams (3-5 Personen) können mit kürzeren Sprints schnell voranschreiten. Definition of Done Komplexität. Wenn Ihre Definition von Done schwere Tests, Sicherheitsreviews oder Compliance-Checks umfasst, benötigen diese Prozesse Zeit. Ein Ein-Wochen-Sprint kann gründliche Qualitäts-Tore möglicherweise nicht unterbringen.

Ein Close-up eines Scrum-Master-Notizbuchs mit einer handgezeichneten Entscheidungsmatrix, die verschiedene Sprint-Rhythmus-Optionen vergleicht

Können Sie die Sprintlänge ändern?

Ja. Und Sie sollten es tun, wenn Ihr aktueller Rhythmus nicht funktioniert. Der beste Zeitpunkt zum Ändern der Sprintlänge ist in einer Retrospektive, in der das Team den Rhythmus als Grundursache von Problemen identifiziert. Häufige Zeichen, dass Sie eine Änderung benötigen:

Das Team kann konsistent keine sinnvolle Arbeit innerhalb des Sprints abschließen

Stakeholder beschweren sich über Sichtbarkeit oder Feedback-Häufigkeit

Zeremonien wirken gehetzt oder aufgeblasen im Verhältnis zur Sprintlänge

Sprint-Ziele wirken entweder zu vage (Sprint zu lang) oder zu eng (Sprint zu kurz)

Die Geschwindigkeit ist erratisch, weil Arbeitsaufträge nicht zur Sprint-Größe passen

Wie man den Übergang vollzieht

Diskutieren Sie auf einer Retrospektive

Nutzen Sie die Retro, um zu ergründen, warum die aktuelle Sprintlänge nicht funktioniert. Sammeln Sie konkrete Beispiele, nicht nur Gefühle. Wenn das Team regelmäßig 40% der Arbeit zum nächsten Sprint überträgt, ist das ein Datenpunkt, der es wert ist, untersucht zu werden.

Probieren Sie die neue Länge für 3-4 Sprints

Ein Sprint reicht nicht aus, um zu beurteilen. Der erste Sprint mit einer neuen Länge wird sich unbeholfen anfühlen, da das Team noch kalibriert. Geben Sie ihm mindestens drei Iterationen, bevor Sie sich entscheiden.

Passen Sie Zeremonie-Längen proportional an

Wenn Sie von zwei-Wochen- auf Ein-Wochen-Sprints wechseln, halbieren Sie Ihre Zeremonie-Zeitlimits. Lassen Sie keine zwei-Stunden-Retro in einen Ein-Wochen- Sprint quetschen.

Neu kalibrieren Sie die Geschwindigkeit

Sprint-Geschwindigkeit übertragen sich nicht direkt zwischen Sprintlängen. Verfolgen Sie Ihre Geschwindigkeit bei der neuen Kadenz und geben Sie dem Team drei Sprints, um eine neue Basislinie zu etablieren. Verwenden Sie einen Sprint-Ziel-Generator, um Ziele angemessen für die neue Länge auszulösen.

Bewerten und entscheiden

Nach der Testphase führen Sie eine fokussierte Retro zur Änderung der Sprintlänge durch. Vergleichen Sie Lieferungs-Vorhersagbarkeit, Team-Zufriedenheit und Stakeholder-Feedback zwischen dem alten und neuen Rhythmus.

Kürzer starten, dann erweitern

Wenn Sie unsicher sind, starten Sie mit Ein-Wochen- oder zwei-Wochen-Sprints. Es ist einfacher, eine Sprintlänge zu erweitern, wenn das Team bereit ist, als eine zu verkürzen, wenn die Dinge nicht funktionieren. Kürzere Sprints bauen agile Muskelgedächtnis schneller auf.

Ein schneller Entscheidungsrahmen

Wenn Sie einen einfachen Startpunkt möchten, verwenden Sie diesen:

Wählen Sie 1-Wochen-Sprints wenn...

Sie ein Startup oder kleines Team sind, sich Anforderungen wöchentlich ändern, Sie die schnellstmögliche Feedback-Schleife benötigen, oder das Team ist neu in Agile und benötigt häufige Übung mit den Zeremonien.

Wählen Sie 2-Wochen-Sprints wenn...

Sie unsicher sind, was Sie wählen sollen, Ihr Team mittlerer Größe (5-7 Personen) ist, Sie ein Gleichgewicht zwischen Feedback-Geschwindigkeit und Ausführungszeit möchten, oder Sie in einer typischen Produktentwicklungsumgebung arbeiten.

Wählen Sie 3-Wochen-Sprints wenn...

Ihre Arbeit schwere cross-team Abhängigkeiten beinhaltet, Integrationstests bedeutende Zeit benötigen, zwei Wochen konsistent zu knapp ist, aber vier Wochen sich wie zu viel Abweichung anfühlen.

Wählen Sie 4-Wochen-Sprints wenn...

Ihr Team erfahren mit Scrum ist, Anforderungen sind stabil, Sie möchten minimalen Zeremonie-Overhead, oder das Produkt ist reif mit einem vorhersehbaren Entwicklungs-Rhythmus.

Was Sie auch wählen, denken Sie daran, dass die Sprintlänge eine Variable ist, keine Konstante. Die besten Teams überprüfen diese Entscheidung regelmäßig und passen sich an, basierend auf dem, was sie lernen.

Zwei Wochen ist bei Weitem die häufigste. Etwa 58% der Agile-Teams verwenden zwei-Wochen-Sprints laut Branchenumfragen. Ein-Wochen-Sprints sind die zweithäufigsten, gefolgt von drei und vier-Wochen-Sprints.

Ja, und sie sollten oft. Ein Platform-Team, das an stabiler Infrastruktur arbeitet, könnte von drei oder vier-Wochen-Sprints profitieren, während ein Product-Team, das auf Markt-Feedback reagiert, möglicherweise ein oder zwei-Wochen- Sprints benötigt. Die Schlüssel-Einschränkung ist Koordination: Wenn Teams häufig synchronisieren müssen, reduzieren ausgerichtete Sprint-Grenzen die Reibung.

Das Ändern der Sprintlänge setzt Ihre Geschwindigkeits-Basislinie zurück. Ein Team, das 30 Story Points in einem zwei-Wochen-Sprint abschließt, wird in einem vier-Wochen-Sprint nicht unbedingt 60 abschließen, da Overhead, Kontextwechsel, und Planungsgenauigkeit sich alle ändern. Verfolgen Sie Geschwindigkeit frisch bei der neuen Länge mit einem Geschwindigkeitsrechner und erlauben Sie drei Sprints für eine zuverlässige Basislinie.

Nicht unbedingt. Viele Teams stellen kontinuierlich bereit, unabhängig von der Sprintlänge. Der Sprint ist ein Planungs-Rhythmus, keine Release-Rhythmus. Aber wenn Ihre Organisation formale Freigaben an Sprint- Grenzen verlangt, bedeuten kürzere Sprints häufigere Freigaben und schnelleres Feedback von Benutzern.