Die ideale Sprintlänge – Ein Drama in 3 Akten

Prolog – Stellen Sie sich vor, Sie sitzen am Sonntag zuhause auf der Couch und surfen in den sozialen Medien. Sie teilen Bilder von Ihrem gut eingefahrenen Jahreswagen, den Sie sich gerade zugelegt haben – todschick, mit allen technischen Finessen und straßenerprobt. Da begegnet Ihnen eine Anzeige des Herstellers: „Deal des Tages“ – Tauschen Sie Ihren Jahreswagen kostenlos gegen unser neues Modell. Warum? Es bietet 2% mehr Kraftstoffeffizienz, weil wir auf Einparkhilfe, Spurwechselassistent und ABS verzichten.Würden Sie diesen „Deal“ eingehen? Ich denke nicht.Und dennoch begegnen mir von Zeit zu Zeit agile Teams, die genau diesen Deal abschließen wollen. Nur steht dort kein Neuwagen zur Diskussion, sondern die ideale Sprintlänge für das Team.

Akt 1 – Der Sündenbock „Meetings“ betritt die Bühne

Die Diskussionen ranken sich dabei in erster Linie um die Regelmeetings. „Zu viel Entwicklungszeit gehe durch diese verloren“, ist dabei ein häufiges Zitat. Die scheinbar naheliegende Lösung ist, die Sprintdauer zu verlängern. Das ist jedoch ein gängiger Irrglaube, mehr dazu in Akt 2.Der Zweck der Regelmeetings ist es, klar definierte Kontaktpunkte des Teams mit festgelegten Zielen zu etablieren: die Planung im Sprint Planning, der tägliche Statusaustausch im Daily, die kontinuierliche Verbesserung in der Retro. Mit diesen Terminen wird ein gemeinsames Verständnis geschaffen. Sei es über die Ziele und Ergebnisse der Iteration, die zu entwickelnden Funktionalitäten oder die Maßnahmen zur kontinuierlichen Verbesserung des Team- und Entwicklungsprozesses. Sie bringen Klarheit in den Entwicklungsprozess und nehmen bei einem 2-Wochen-Sprint auch gerade einmal 13% der verfügbaren Zeit in Anspruch.Das darüber hinaus noch Meetings bestehen, die die Organisation sich selbst auferlegt, steht auf einem ganz anderen Blatt. Das liegt meist an den bestehenden Abhängigkeiten, wenn beispielsweise Business, IT-Betrieb und IT-Entwicklung nicht Seite an Seite arbeiten, sondern aus organisatorischen Silos heraus. Wenn die Scrum-Meetings einfach „on-top“ dazukommen, dann entsteht bei den Teams der Eindruck, dass sie weniger Zeit haben. Dann sollte aber der Fokus darauf liegen, diese Abhängigkeiten abzubauen. Wie das gehen kann, können Sie in unserem BizDevOps-Whitepaper lesen.

Akt 2 – Die Wahrheit erlöst den Sündenbock

Die Entwicklungszeit zu steigern, indem die Sprints verlängert werden, ist ein gängiger Irrglaube. Denn wenn wir nüchtern auf die Dauer der Meetings im Scrum-Prozess schauen, dann verändert sich durch die Sprintlänge so gut wie gar nichts.Selbst bei einer extremen Sprint-Verlängerung von einer auf vier Wochen wächst die effektive Entwicklungszeit für die Entwickler über den ganzen Zeitraum nur um maximal 3 Prozentpunkte. Eine Vergleichsrechnung schafft hier Transparenz.Prämissen für eine Vergleichsrechnung:

• Zur Vergleichbarkeit werden die Sprintlängen über einen 4-Wochen-Zeitraum betrachtet
• Eine Arbeitswoche hat 40 Stunden
• Zur Vereinfachung ist der Sprintbeginn am Montag, Sprintende am Freitag
• Sprint Planning I & Sprint Planning II skalieren mit der Sprintlänge (Dauer = jeweils 1h/Sprintwoche), sie finden jeweils einmal im Sprint statt
• Review, Retro skalieren nicht, dauern jeweils 90 Minuten und finden einmal im Sprint statt
• Das Backlog Refinement skaliert mit der Sprintlänge (Dauer jeweils 0,25h pro Sprintwoche) und findet einmal im Sprint statt
• Ausnahme ist der 1-Wochen-Sprint: Hier sind Review, Retro nur 1h lang, Backlog Refinement dauert 0,5h

Im Ergebnis schaut eine detaillierte Betrachtung der Meeting- und Entwicklungszeit pro Woche bei Sprintlängen von einer bis vier Wochen unter den obigen Prämissen dann wie folgt aus: 1-Wochen-Sprints2-Wochen-Sprints3-Wochen-Sprints4-Wochen-SprintsØ Meetingzeit pro Woche14%13%13%11%Ø Entwicklungszeit pro Woche86%87%87%89%Maximale Entwicklungszeit in einer Woche des Sprints86%88%95%97%Minimale Entwicklungszeit in einer Woche des Sprints86%87%82%77%Wie oben erwähnt, entsteht die größte Differenz in der durchschnittlichen Entwicklungszeit pro Woche bei einem Wechsel der Sprintdauer von einer zu vier Wochen. Aber selbst hier sprechen wir nur von 3 Prozentpunkten mehr Entwicklungszeit. Das sind knappe 5 Stunden für jeden Entwickler über einen Zeitraum von vier Wochen. Gerade einmal 75 Minuten pro Woche.Der Zeitgewinn beim Sprung von einer Sprintdauer von zwei Wochen, wohl die häufigste Form, zu einem vierwöchigen Sprint beträgt nur noch 50 Minuten pro Woche. Die Frage ist: Zahlt sich das wirklich aus?

Akt 3 – Der Sündenbock wird zum Helden

Rechnet und normiert man die Meetinganteile an den Sprintlängen, dann wird sehr schnell deutlich, dass sich der erwartete positive Effekt einfach nicht einstellt. Das kommt im Wesentlichen davon, dass bei einer längeren Sprintdauer die Planungsmeetings Sprint Planning I & II in der Länge mitskalieren müssen. Denn ich möchte in mehr Zeit mehr umsetzen und muss deshalb auch mehr planen.Und es bleibt nicht dabei: Selbst wenn die 2-3 % mehr Entwicklungszeit eine Verlängerung der Sprintdauer wert sind, werde ich in derselben Zeit (vier Wochen) weniger Feedback bekommen, meine Kunden seltener einbinden und Impediments weniger schnell erkennen.Denn es macht einen erheblichen Unterschied, ob ein Review alle zwei oder alle vier Wochen stattfindet. Zudem werden Impediments im Entwicklungsprozess weniger deutlich sichtbar, weil sich in einem Vier-Wochen-Sprint einfach viel mehr Wartezeiten einschleichen können. Eine User Story, die mit hohen Wartezeiten nach drei Wochen fertig ist, fällt in einem Vier-Wochen-Sprint nicht wirklich auf. In einem Zwei-Wochen-Sprint schon, weil in diesem Fall das Team sein Commitment nicht hält.Als Kontrast: Große Technologieunternehmen liefern heute täglich aus. Das sollte auch der Anspruch sein, insbesondere in der IT, weil regelmäßiges Liefern der Nordstern für kontinuierliche Verbesserungen ist.Ist die Diskussion um die Sprintlänge in Ihrer Organisation ein Dauerbrenner? Gern schaffen wir dazu Transparenz in Ihrem Unternehmen. Treten Sie in den Austausch mit uns.

‍Bild: Unsplash License, Tim Gouw