Sprintdauer bei Scrum – kurz oder lang?

Die Sprintdauer

In dieser Woche kam im Coaching mit dem Product Owner ein interessantes Thema auf. Die Sprintdauer. „Grundsätzlich ist es eine bedeutende Frage, die es sicherlich zuerst einmal in der Retrospektive aufzubringen gilt“, war meine erste Antwort. Dann legte ich nach: „Wenn wir das Thema jedoch neutral beleuchten möchten, kann ich sehr gerne mal die Unterschiede zwischen einer kurzen und langen Sprintdauer aufzeigen“. Der Product Owner war erleichtert, denn er wollte mit diesem Thema nicht gleich zum Team.

Seine Motivation, die Sprintdauer zu verlängern, ist getrieben von dem Gefühl, dass er in den letzten Wochen und Monaten von der Organisation erdrückt zu werden. Immer einen Schritt zu spät dran zu sein. Wie beim Fussball, wenn man dem Ball immer hinterher läuft ohne ihn je zu bekommen. Erwähnenswert ist, dass sich das Unternehmen in einem Agilen Transition befindet.

Aus diesem Coaching heraus, das zeitlich limitiert war, ist folgende Gegenüberstellung entstanden:

Lange Sprintdauer

  • Weniger „Inspect & Adapt“ Phasen, damit auch weniger Möglichkeiten zu lernen und sich anzupassen und schliesslich sich zu verbessern.
  • Erlaubt dem Scrum Team eine Atmosphäre und Wahrnehmung, in der sie nicht das Gefühl haben permanent „gehetzt“ zu sein.
  • Geringere Planungsfrequenz.
  • Geringere Flexibilität für den Product Owner.
  • Hat manchmal etwas von „Festhalten an einem Plan“, statt „Reagieren auf Veränderungen“.
  • Es bedarf akribischer Vorbereitung für den Product Owner um den Sprint nicht zu verändern, vor allem je länger er dauert.
  • Bei größeren Projekten mit multiplen Teams können erfahrungsgemäss mehr und genauere Abklärungen erfolgen.

Kurze Sprintdauer

  • Hohe Planungsfrequenz.
  • Hohe Flexibilität für den Produkt-Owner.
  • Ideal um unvorhergesehene, „unplanbare Bugs planbar zu machen. Bei 4-Wochen Sprints wird der Sprint gestört und bei 1-Wochen Sprints kann der Bug idealerweise in der nächsten Woche umgesetzt werden. Show-Stopper bzw. Blocker sind davon ausgenommen.
  • Schnelleres und häufigeres „Inspect & Adapt“, bzw. „Lernen & Anpassen“, dadurch häufigere Umsetzung von Verbesserungs- bzw. Optimierungspotenzialen. Potential um schneller besser zu werden.
  • Bei kleineren Teams führen Abwesenheiten Krankheitsausfälle, Weiterbildungen und Urlaub zu enormen Lieferschwankungen.
  • Potential besteht, dass der Product Owner in den User Stories unpräzise und unvollständig wird, da aufgrund des engen Zeitplanes notwendige Abklärungen für die Anforderungen häufig auf der Strecke bleiben.
  • Hoher Stressfaktor für den Produkt-Owner und auch für das Entwicklungsteam, da jede Woche „geliefert“ werden muss.
  • Kontinuierliche Belastung für das Scrum Team, vor allem wenn das Team starke Abhängigkeiten hat. Potential um die Beteiligten „auszubrennen“ (Burndout).
  • Nahezu Pflicht für Produkte bzw. Projekte die auf saisonale oder marktdynamische Anforderungen sofort reagieren müssen.

Diese Diskussionspunkte sind keineswegs vollständig. Sie können für ähnliche Fragestellungen als Einstieg genutzt werden.

Sollten Sie weitere Argumente für eine kurze oder lange Sprintdauer im Kopf haben, freue ich mich über jedes Einzelne, dass Sie ergänzen.

Ihr Dr. Patrick Seifried
xingtwitterlinkedin

Noch keine Kommentare bis jetzt

Einen Kommentar schreiben