Vor einiger Zeit hatte ich über die Fünf Schwachpunkte von Scrum gebloggt. Am Ende des Artikels hatte ich versprochen, mir Gedanken darüber zu machen, wie man diese Schwierigkeiten besser meistern kann. Mein erstes “Scrum-Schwachstellenthema” ist heute die Sprintdauer. Eingangs möchte ich noch einmal kurz erläutern, was denn nun an der Sprintdauer so schwierig ist und wieso es meiner Meinung nach eine Schwachstelle ist.

In vielen Fachblättern und Artikeln wird eine Sprintdauer von 30 Tagen (4 Wochen) vorgeschlagen. Manchmal findet man auch 2-4 Wochen als empfohlene Sprintdauer. In jedem Fall aber sollte die Sprintdauer stabil über Sprints hinweg bleiben.

Mein Einwand: Die Sprintdauer ist eine Schwachstelle in Scrum. Besser gesagt: lange Sprintzyklen sind eine Gefahrenquelle für den Erfolg von Scrum-Teams. Denn gerade lange Sprintzyklen sind für die meisten Teams der erste große Fallstrick. Die meisten Teams, die mit Scrum beginnen, fangen mit langen Sprints von 4 Wochen und z.T. sogar mehr an. Schwierig in mehrfacher Hinsicht, denn dadurch berauben sie sich eigenmächtig der Vorteile agiler Verfahren. Die Flexibilität wird eingeschränkt, die Feedbackschleife des Inspect & Adapt wird verlängert und dem Team wird hohe Planungskompetenz bzw. -verantwortung aufgebürdet.

Was kann man tun um diesen Risiken entgegenzuwirken? Ganz einfach: Kurze Sprints! Mit kurzen Sprints meine ich auch kurze Sprints. Aus meiner Sicht ist die ideale Sprintdauer eine Woche lang. Ja, richtig gelesen, nur 5 Werktage! Jede Woche Planung, jede Woche Review, jede Woche Retro.

Daily Scrum, Weekly Sprint

Was erreicht man dadurch? Zunächst einmal schafft man durch so eine kurze Sprintdauer eine hohe Planungsfrequenz. Das ist für fast alle Beteiligten nur von Vorteil. Der PO hat hohe Flexibilität, während das Team einen sehr überschaubaren Planungszeitraum hat. Das Team geht genauer auf die Stories und das Design ein, bricht in der Planung genauer Tasks auf. Dadurch ergeben sich quasi automatisch verbesserte Schätzung und stabiles Commitment. Das wiederum stärkt die Vorausplanung und Releaseabstimmung auf der Product Owner-Seite.

Ein-Wochen-Sprints bedeuten aber auch schnelleres Inspect & Adapt. Jede Woche gibt es eine Retrospektive, das wichtigste agile Gremium in Scrum. Jede Woche eine Retrospektive zu haben ist ein wenig wie “und wöchentlich grüßt das Scrumeltier” – es kommen Anfangs immer wieder die gleichen Themen ins Gespräch. Das liegt vor Allem daran, dass es viel einfacher ist, wöchentlich “inspect” zu betreiben, als effektiv “adapt” durchzuführen. Doch genau das ist das schöne am schnellen, wöchentlichen Sprint-Puls. Es wird die Agilität förmlich “antrainiert”. Das Team lernt wesentlich schneller, wirklich zu adaptieren, anstatt es irgendwie auf die lange Bank zu schieben.

“Accelerate” für eine gute “Velocity”

Ein nicht ganz auf den ersten Blick erkennbarer Vorteil der Wochensprints ist der schnelle “Ramp-up” des Teams zur stabilen Velocity. Während ein Team mit 4-Wochen-Sprints nach den ersten 3-5 Sprints (also nach 3-5 Monaten!) erst so halbwegs stabile Produktivität und Schätzkompetenz aufweisen kann, gelingt einem Team mit Wochensprints nach der gleichen Sprintzahl (also nach 3-5 Wochen) noch mehr. Ergo: Ein zügiges Teaming wird erreicht.

Gerade Wochensprints haben meiner Meinung nach die Bezeichnung “Sprint” verdient. Denn wöchentliche Iterationen “fühlen” sich nicht nur wie ein Sprint an, sondern sind auch so intensiv und ergiebig wie ein Sprint. Das liegt nicht nur am höheren Takt, sondern auch an einer ganz lapidaren Tatsache: Die Arbeitswoche.

Unsere gesamte Lebens- und Arbeitskultur tickt in diesem “Wochentakt”. Viele denken, planen und organisieren in Wochenzyklen. Das kommt auch dem wöchentlichen Scrumsprint zu Gute. Teams mit Wochensprints kommen mit dem Wochentakt “einfach besser zurecht” – wissentlich oder unwissentlich. Höchstwahrscheinlich ist dies dem Fakt geschuldet, dass die gesamte Arbeitswelt sich an diesem Takt orientiert. Egal ob nun Scrum oder nicht, die Kalenderwoche ist und bleibt eine präsente Zeiteinheit, die für Planung, Vereinbarung und Organisation angewendet wird.

Kurz und Knackig

Bei all den Vorteilen, die eine kurze, nach meinem Ermessen am Besten wöchentliche Sprintdauer hat – es gibt auch hier wieder einige Dinge, die man vor der Einführung oder beim “Sprinten” beachten sollte. Ein allgemeiner Fallstrick kann es werden, die Planung des Sprints auf den Montag zu legen, und die Retrospektive auf den Freitag. So wie es bei klassischen Jour-Fixe Meetings zum guten Ton gehört Planungsgespräche an das Ende der Woche zu legen, ist das bei Wochensprints auch förderlich. Eine mögliche Variante wäre es, die Planung auf den Freitag zu legen und Review/Retro auf Montag.

Damit ist der nächste Achtungspunkt schon implizit genannt: Nicht versuchen, alle “Scrum-Meetings” in einen Tag zu quetschen. Ganz im Gegenteil, die Planung kann Freitag vormittags erfolgen. Der Nachmittag ist reserviert für Konzentrationsarbeit, Tageskommunikation, Vorbereitung des Boards und des Reviews / Retro’s.

Montag ist vormittags “Tabu” – denn genau dann befindet man sich in der “Twilight Zone”. Ende des letzten Sprints oder Anfang des nächsten Sprints – schon durch die Planung oder noch im Review – noch Montagsmüde oder schon im Tatendrang – ein Montag Morgen eben. Der späte Nachmittag kann dann nach dem üblichen Daily für die kurze Review/Retro investiert werden. Bei Wochensprints ist eine 4 stündige Planung angemessen, eine Review/Retro von einer Stundes komfortabel ausreichend.

Fazit: Kurz & Knackig – das ist die bessere Sprintdauer in Scrum!
Es gibt natürlich noch mehr Aspekte als die aufgeführten, um zu einer ausgewogenen Sprintdauer für sein Team zu kommen. Für mich bleibt jedoch die in den meisten Fällen zutreffende Erkenntnis: Kurz & Knackig ist besser als Lang & Weilig. Was denken Sie? Ihre Meinung ist gefragt!