Agile Minds

Längere Sprints sind der Weg zur dunklen Seite!

Alle zwei Wochen ein Sprintwechsel ist anstrengend. Sprint Review, Sprint Retro, dann noch das Sprint Planing, das kostet alles viel Zeit und auch Nerven. Wenn die Sprints drei oder vier Wochen lang wären, kosten diese „Sprintwechsel Meetings“ im Verhältnis viel weniger Zeit.

So oder so ähnlich beginnt meist eine gefährliche Änderung eines etablierten Scrumprozesses basierend auf einer falschen Annahme und ohne die Gegenargumente zu beleuchten. Die Annahme, man spare Zeit ist vielleicht ja noch qualitativ richtig, quantitativ betrachtet fällt die Zeitersparnis aber gar nicht so hoch aus: Natürlich dauern Sprint Review und Sprint Retrospective deutlich länger, wenn die Sprintdauer größer ist. Beim Sprint Planing ist dies sogar noch eklatanter, denn es ist viel viel aufwendiger für eine längere Zeitdauer zu planen, als für eine kürzere. Ganz abgesehen von einem deutlich höheren Risiko, sich zu verschätzen und die Committments deshalb zu verwässern.

Hier an dieser Stelle deshalb eine Liste von Argumenten, einen Sprint eher kürzer als länger zu machen.

Argumente gegen eine Verlängerung des Sprints

  • Es müssen deutlich mehr User Stories aus dem Backlog ready sein, um einen Sprint starten zu können.
  • Sprint Planing deutlich aufwendiger: Es müssen mehr User Stories für den Sprint geplant – also besprochen – werden.
  • Es ist für ein Scrum Team deutlich schwerer sich für 3 Wochen zu kommitten, denn es ist viel schwerer für 3 Wochen abzuschätzen, ob man es schaffen kann oder nicht. „Mini Wasserfall“.
  • Die Komfortzone für den Product Owner wird verlockend groß: Die User Stories können ruhig „fetter“ werden und müssen – vermeintlich – nicht mehr weiter heruntergebrochen werden.
  • Die Komfortzone für das Team wird verlockend groß: Wenn man noch drei Wochen Zeit hat, etwas zu erledigen, ist die Gefahr größer, nicht vehement genug an einer Sache dranzubleiben. Sorry; ist so. Wir sind alle Menschen.
  • Das Verlangen von außen in das Team einzugreifen und kurzfristig Dinge nebenher erledigen zu lassen – oder dies zumindest zu versuchen – wird sehr groß.
  • Weniger Möglichkeiten aufgrund der wenigen Sprint Retrospectives den „inspect and adapt“ Schritt durchzuführen. „Weniger Raum für das Team sich zu verbessern“.
  • Weniger Möglichkeiten für den Product Owner aufgrund der wenigen Sprint Reviews den „inspect and adapt“ Schritt durchzuführen. Zumindest den „adapt“ Teil, denn den „inspect“ Teil kann der Product Owner ja stets durchführen. „Weniger Raum für den Product Owner das Produkt zu verbessern“.

Kategorien:Agile Minds