Scrum: Wie lange dauert ein Sprint idealerweise?

Scrum basiert auf so genannten „time-boxed“-Elementen, das heißt, wir geben uns selbst einen festen Zeitrahmen für Besprechungen und Arbeitszeiten vor und schauen dann, was in diesen Zeitrahmen hineinpasst. Das ist einer der wichtigen Unterschiede zu klassischen Projektmanagement-Methoden, die ein festes Ziel vorgeben und dann zu ermitteln versuchen, wie lange denn die Erreichung des Ziels dauern könnte (und damit oft genug scheitern). Das bedeutet nicht, dass wir in Scrum keine größeren Ziele vorgeben und erreichen können. Nur nutzen wir eben die Macht der Gewohnheit und machen gleichmäßige, gut abgewogene Schritte hin zum Ziel, anstatt am Anfang entspannt loszulaufen und später in Hektik zu verfallen.

Die ideale Sprintlänge in Scrum finden

Wie also sieht eine gute Sprintlänge aus? Bei der Einführung von Scrum in meinem aktuellen Unternehmen im Jahr 2015 habe ich eine Zeit lang die Produktivität (Velocity) meines Teams bei verschiedenen Sprintlängen (2, 3 und 4 Wochen) beobachtet und durch die Anzahl der im Sprint verfügbaren Manntage geteilt. Das Ergebnis in meinem Test: Je länger ein Sprint wurde, desto mehr sank die Produktivität. Wie man im Chart sehen kann, scheint es eine negative Korrelation zwischen der Anzahl der Manntage in einem Sprint (braune Kurve) und der Produktivität (orange Kurve) zu geben.

 

Wie lange dauert also der ideale Sprint in Scrum?

Ein Grund für diesen Effekt könnte die Beobachtung sein, dass jede Aufgabe gerne die Zeit ausfüllt, die man ihr gibt. Sprich: Drei- oder vier-Wochen-Sprints fühlen sich zu Beginn recht entspannt an und geben damit kein ausreichend großes Gefühl von Dringlichkeit. Es könnte auch daran liegen, dass mehr Aufgaben in einem größeren Sprint sich für den einzelnen Entwickler unklarer und unübersichtlicher anfühlen und deswegen die Bereitschaft sinkt, die Themen anzugehen.

Zwei Wochen sind (für uns) die ideale Länge

Wie schon gesagt, handelt es sich hier um einen nicht repräsentativen Test mit einem einzelnen Entwicklerteam. Trotzdem kann ich aus der Erfahrung bestätigen: Zwei Wochen haben sich bei uns als ideale Sprintdauer erwiesen. Ein-Wochen-Sprints haben wir übrigens nicht ausprobiert, weil wir die Stakeholder nicht jede Woche zu einer Review bitten wollen.