Scrum Sprintlänge

Faktor: Aufwand der Entwicklung 

Um gute Ergebnisse zu schaffen, benötigt die Entwickler Zeit. Um die passende Sprintlänge zu finden gilt es also, zu hinterfragen, wie viel Zeit notwendig ist, um Ergebnisse in der gewünschten Qualität hervorzubringen. Die Entwickler werden grundsätzlich eher zu längeren Sprints tendieren. Um eine balancierte Einschätzung zu treffen, gilt es, weitere Faktoren in Betracht zu ziehen. 

Faktor: Dynamik im Umfeld 

Dem Wunsch nach ausreichend Zeit für die Hervorbringung von Ergebnissen, steht die Dynamik der Umgebung, beispielsweise die Marktsituation und Kundenwünsche gegenüber. Wenn Teams in einem besonders dynamischen Umfeld arbeiten und während des Sprint mit viel ungeplanter, zusätzlicher Arbeit konfrontiert werden, empfiehlt es sich, die Sprintlänge eher kürzer zu wählen.

Faktor: Vertrauen des POs

Das Team arbeitet in Scrum selbstorganisiert und übernimmt Verantwortung für den Sprint. Der Product Owner steht dabei für Fragen zu Verfügung und wird im Falle von Problemen frühzeitig in die Arbeit eingebunden. 

Damit dieses Zusammenspiel über einen längeren Sprintzyklus von beispielsweise vier Wochen funktionieren kann, benötigt es ein intaktes Vertrauensverhältnis zwischen Entwicklern und Product Owner. Dieses ist besonders am Anfang einer Zusammenarbeit oft noch nicht ausgeprägt genug. Dies hat zur Folge, dass Product Owner nach einer gewissen Zeit anfangen, enger zu überwachen oder gegebenenfalls sogar aus Angst, am Ende des langen Sprints zu scheitern, Einfluss nehmen und nach steuern. Es empfiehlt sich also, das Vertrauensverhältnis bei der Festlegung der richtigen Sprintlänge zu hinterfragen und besonders am Anfang eine kürzere Sprintlänge zu wählen. 

[INSERT_ELEME.   NTOR id=“15519″]

Faktor: Schnelles Lernen

Je kürzer der Sprintzyklus, desto schneller der Lerneffekt. Scrum Master tendieren daher häufig zu kurzen Sprints, um diese Lerneffekt zu forcieren. In der Praxis beobachte ich, dass Teams nach ca. drei bis vier Sprints eingespielt sind – unabhängig von der Sprintlänge. Bei einwöchigen Sprints bedeutet das, dass Teams sich bereits nach drei oder vier Wochen gemeinsam als Team sehr weit entwickelt haben. Im Vergleich dazu sind Teams bei einer Sprintlänge von vier Wochen erst viel später an diesem Punkt. Es empfiehlt sich also, auch aufgrund der schnell eintretenden Lerneffekte, die Sprintlänge eher kürzer zu gestalten. 

Faktor: Disziplin

Ein kurzer Sprintzyklus von einer Woche hat den großen Vorteil, als Team sehr schnell eingespielt zu sein. Darüber hinaus ist man wesentlich reaktionsfähiger, als bei langen Sprints. Die Umsetzung von sehr kurzen, beispielsweise einwöchigen Sprints, erfordert insgesamt allerdings ein sehr hohes Maß an Disziplin. Dies setzt eine hohe Fokussierung innerhalb der unterschiedlichen Scum Events voraus. Sie müssen auf den Punkt sein und ihren Sinn und Zweck erfüllen, damit effektiv weitergearbeitet werden kann. Dies bedingt ebenfalls eine optimale Vorbereitung. Aufgrund der schnellen Lerneffekte und der Reaktionsfähigkeit wären einwöchige Sprints sehr wünschenswert. In der Praxis zeigt sich jedoch, dass das notwendige Maß an Fokussierung häufig nicht umzusetzen ist. Wenn die Entscheidung getroffen wird, einwöchige Sprints umzusetzen, sollte man sich über die dafür notwendige Disziplin im Klaren sein. 

30 Tage Sprint als Obergrenze

Dass der Scrum Guide für Sprints eine Obergrenze von 30 Tagen festgelegt hat, ist jedoch sinnvoll. Die Intention dahinter findet sich in der empirischen Steuerung, auf der Scrum als agile Methode basiert. Konkret bedeutet das, dass Lernen aus der Erfahrung heraus ein wichtiger Bestandteil dieser agilen Arbeitsweise ist. Sprint für Sprint wird dabei das Ergebnis inspiziert (inspect) und dementsprechend Maßnahmen daraus abgeleitet (adapt). Die Obergrenze von 30 Tagen soll sicherstellen, dass dieser Austausch regelmäßig und oft genug stattfindet, um diese Erfahrung schnell aufzubauen. 

Die Intention dahinter wird besonders deutlich, wenn man sich vor Augen hält, was passieren würde, wenn das Ergebnis nicht in kurzen Zeitabständen betrachtet wird und der Sprint auf einen längeren Zeitraum (z.B. auf ein halbes Jahr) gedehnt wird. Die Konsequenz daraus wäre, dass das Team im Rahmen einer “eingefrorenen” Umgebung für ein halbes Jahr an einem Produkt arbeitet und das Ergebnis erst nach sechs Monaten betrachtet. Zum einen ist es sehr wahrscheinlich, dass sich die Gegebenheiten in diesem Zeitraum bereits wieder geändert haben und das Ergebnis nicht mehr dem entspricht, was eigentlich gebraucht wird. Darüber hinaus ist es sehr wahrscheinlich, dass diese Arbeitsweise mit einer vorgeschalteten Planung im klassischen Sinne einhergehen würde. Das Resultat ist klar: Scrum ist dann einfach nicht mehr Scrum. Es ist also wichtig, dass Sprints nicht zu lange sind. Die Obergrenze von 30 Tagen sollte meiner Meinung nach daher unbedingt eingehalten werden, um “inspect and adapt” auch wirklich zu leben.

Diskussionen über längere Sprints

In der Praxis erkenne ich häufig, dass Gespräche und Diskussionen über die passende Sprintlänge mit einer Dysfunktion in der Umsetzung von Scrum einhergehen. Diese werden nämlich nach Abschluss eines Sprints besonders sichtbar. Um Missstände zu beseitigen, muss an dieser Stelle eine Auseinandersetzung mit den Problemen erfolgen. Ich erkenne häufig, dass diese Auseinandersetzung nicht stattfindet. Vielmehr versuchen die Beteiligten, teils bewusst, teils unbewusst, das Problem durch eine Veränderung der Sprintlänge zu lösen. “Wir brauchen mehr Zeit” ist dann das Standardargument. 

Gründe, die den Wunsch nach einem längeren Sprintzyklus aufkommen lassen, sind unterschiedlich. Eine Dysfunktion zeigt sich häufig in der suboptimalen Zusammenarbeit als Team. In diesem Szenario zeigt sich in der Praxis immer wieder, dass Teams nicht zusammenarbeiten, sondern jedes Teammitglied sich “in seine Ecke verzieht”, um alleine an einem Teil des Produktes zu arbeiten. Austausch und gegenseitiges Aushelfen finden kaum statt. Der Gedanke, alle Teile des Produktes am Ende eines Sprints zusammenzusetzen und ein funktionierendes Ergebnis zu erhalten, erweist sich aber meist als unrealistisch. Am Ende des Sprints wird dieses Problem dann radikal sichtbar, indem das Ergebnis nicht zufriedenstellend oder unfertig ist. Eine Ausweitung des Sprintzyklus wird hier jedoch keine Abhilfe schaffen. Im Gegenteil: Dadurch, dass der Sprint verlängert wird, vergrößern sich auch die Probleme. Meine Empfehlung ist es daher, eine gewünschte Verlängerung des Sprints kritisch zu hinterfragen und zu analysieren, ob eine mögliche Dysfunktion das Problem sein könnte, welches dadurch nicht gelöst wird, sondern lediglich aufgeschoben oder gar verschlimmert wird.  

Resümee zur Findung der passenden Sprintlänge

Um schnell zu lernen und sich als Team weiterzuentwickeln ist es wichtig, eine Sprintlänge unter 30 Tagen zu wählen. Viele Teams arbeiten mit zweiwöchigen Sprintzyklen. Eine pauschale Antwort auf die Frage nach der richtigen Sprintlänge gibt es jedoch nicht. Jedes Team muss basierend auf unterschiedlichen Faktoren (Dynamik des Umfelds, Vertrauen zwischen Team und PO, passende Lerngeschwindigkeit und Disziplin) entscheiden, was die passende Sprintlänge darstellt. Der Wunsch nach längeren Sprintzyklen resultiert nicht selten aus einer vorhandenen Dysfunktion. Eine Veränderung der Sprintlänge sollte daher kritisch hinterfragt werden.