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, per LinkedIn, XING und gern persönlich.Bild: Unsplash License, Tim Gouw

Agile Toolbox
Scrum
Scrum Meetings
Team
Stefan Nagel
July 3, 2020

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Warum macht ihr eigentlich kein SAFe?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Transformation

FRAGE: Was kostet eine agile Transformation?

Agile Management
Agile Organization
Agile Toolbox
Leadership
Agiles Lernen

FRAGE: Welche Rolle spielt Training?

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

Agile Management
Agile Organization
Agile Tools
Agiles Management
Leadership

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Führung

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

Agile Management
Agile Organization

FRAGE: Warum sollten wir mit borisgloger arbeiten?

Agile Management
Agile Organization
Agiles Management
Transformation

FRAGE: Wie viel kostet eine Beratung und ist es wirklich rentabel bei borisgloger?

Agile Prinzipien
Agile Toolbox
Projektmanagement

The Lie Behind the Parable of the Golf Balls and the Jar

Video
Change
Digitale Transformation
Hardware
Agile Organization

Agile in Industrial Automation: The Digital Transformation of Yokogawa

Versicherung
Neues Arbeiten
Führung
Agile Prinzipien
Kundenfokus

Kundenzentrierte Versicherung: Kann ein agiles Projekt die Organisation retten?

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

Agilität in den Vertrieb bringen – für Versicherer sinnvoll

Versicherung
Agile Prinzipien
Kundenfokus
Agile Toolbox
Produktentwicklung

BizDevOps in der Versicherungsbranche – Wie multidisziplinäre Teams wirklich besetzt sein sollten

Versicherung
Agile Prinzipien
Kundenfokus
Neues Arbeiten
Meetings

Undercover Agile für Versicherer: 5 agile Praktiken für Ihr klassisches IT-Projekt

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

IT-Projekte in der Versicherungsbranche – Das Rennen um die Time-to-Market

Team
Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills

Umgang mit Fehlern & Diversität – Erfolgreiche agile Teams #2

Team
Neues Arbeiten
Agile Toolbox
Produktentwicklung

Das Geheimrezept von High-Performance-Teams

Team
Arbeiten bei borisgloger consulting
Agile Prinzipien
Freiwilligkeit
Selbstorganisation

Konsent und offene Wahl: 2 Prinzipien aus der Soziokratie, die jedes agile Team gebrauchen kann

Team
Neues Arbeiten
Meetings
Social Skills

Der agile Adventkalender

Team
Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Agile Prinzipien

Selbstorganisation der Teams fördern: Ask the team!

Team
Agile Toolbox
Design Thinking

Who Recognizes the Truly Good Ideas?

Team
Agile Organization
Transformation

Pizza Is Not Dead, and Neither Is Agility

Scrum4Schools
Neues Arbeiten
Führung
Life
Social Skills

Trauen wir unseren Kindern mehr zu – auch in der Schule!

Scrum4Schools
Change
Agiles Lernen
Neues Arbeiten
Remote Arbeiten

Eine Scrum4Schools-Projekt-Rückschau mit Physiklehrer Ivan Topic

Scrum4Schools
Mehr Formate
Interview
Nachhaltigkeit

Mit Scrum4Schools dem Weltraum auf der Spur

Scrum4Schools
Change
Agiles Lernen

Scrum4Schools - ein Projekt nimmt Fahrt auf

Scrum4Schools
Agile Schulentwicklung
Agile Toolbox

Technik im Alltag - Scrum4Schools zu Gast in Langenzersdorf

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps

Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

Projektmanagement
Agiles Management
Agile Toolbox
Scrum
Enterprise Scrum

Das Management in Scrum

Projektmanagement
Change
Digitale Transformation

Agilität in der Logistik oder: Liefern wie Amazon

Projektmanagement
Agile Toolbox
Scrum

Meilensteine und Scrum

Portfoliomanagement
Project management

Too many projects? Portfolio management simplified

Neues Arbeiten
Mehr Formate
Agile Toolbox
Scrum
Scrum Values

Wie agiles Arbeiten die Kommunikation aus der Selbstverständlichkeit holt

Neues Arbeiten
Change
Agiles Lernen
Mehr Formate
Audio

New Learning heute für das New Work von morgen – mit Angelika Weis

Neues Arbeiten
Change
Soziale Innovation

New Work Experience 2019 – ein Erfahrungsbericht

Neues Arbeiten
Audit
Change

Agil im Audit: das Starter-Kit

Neues Arbeiten
Agile Toolbox
Scrum
Scrum4Schools
Agile Prinzipien

Scrum4Schools: Lernen für die Zukunft

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Meetings
Retrospektive

Arbeiten wir uns gesund!

Neues Arbeiten
Agile Toolbox
Scrum
ScrumMaster-Praxistipps

Who should be in (agile) HR?

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Values

Glauben Sie an die Seele Ihrer Firma?

Neues Arbeiten
Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freiwilliges Teilen von Wissen – Erfolgreiche agile Teams #5

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Doing vs. Being Agile – Erfolgreiche agile Teams #1

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freude bei der Arbeit & Sustainable Pace – Erfolgreiche agile Teams #3

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Anpassungsfähigkeit & schonungslose Offenheit – Erfolgreiche agile Teams #4