Der Sprint in Scrum
Scrum organisiert die Wertschöpfung in Iterationen, sogenannten Sprints. Sprints sind in Scrum zunächst einmal nichts anderes als Timeboxen, also einfach nur eine Zeiteinheit. Nicht mehr, aber auch nicht weniger.
Damit – und das ist der interessante Aspekt an Scrum – führt Scrum ein anderes Paradigma des Zeitmanagements ein.
Auch Wasserfall kennt bestimmte Phasen wie Spezifikationsphase, Implementierungsphase, Testphase, Dokumentationsphase, Abnahmephase, etc.
Hier aber sind die Zeitabschnitte an bestimmten Content gebunden und der Content bestimmt letztlich die Länge des Zeitabschnittes. Die Phase ist beendet, wenn die Ziele dieser Phase erreicht sind bzw. zumindest zufriedenstellende Ergebnisse geliefert hat.
Scrum dreht das Verhältnis zwischen Timebox und Content genau um. Die Timebox, also die Länge des Sprints ist klar definiert und sollte sich möglichst selten ändern. Dazu kommen wir gleich noch.
Warum ist die Sprintlänge so wichtig?
Variabel ist der Content, genauer der Scope, der in dieser Timebox geliefert werden soll.
Auf dem ersten Blick scheint dieser Paradigmenwechsel erforderlich zu werden wegen vertikaler (end-2-end) und featureorientierter Entwicklung, die Scrum einführt. Aber das Entkoppeln von Timebox und Scope eröffnet Scrum-Teams noch mehr Möglichkeiten.
Das Entkoppeln von Timebox und Scope eröffnet eine wesentlich größere Flexibilität. Bei der Wahl der Länge eines Sprints kann plötzlich auf andere Dinge Rücksicht genommen werden, als nur auf den Scope.
Die Sprintlänge wird damit mehr zu einem strategischen Instrument um den Flow von Value besser zu unterstützen. Folgendes Beispiel verdeutlicht das:
Welche Rolle spielen Scope Changes im Scrum Sprint?
Neben Bugs sind ständige Scope-Changes mitten im Sprint nicht nur ein Ärgernis von Scrum Teams, sondern sie sind vor allem sehr teuer und ein absoluter Velocity-Killer.
Crossfunktionale Teams haben sich während des Plannings, dass ja mit allen Aktivitäten zusammengenommen, mehrere Tage Aufwand (nicht Dauer) über alle Teammitglieder hinweg kostet, viel Mühe gegeben, einen Scrum Sprint perfekt auszubalancieren.
Ein Scope-Change zerstört sofort diese Balance, ein Replanning ist notwendig und all das kostet.
Teams, die sich ständig Scope-Changes gegenübersehen, könnten die Länge der Sprints z.B. auf eine Woche verkürzen, gegebenenfalls auch nur für eine Phase
In der Zwischenzeit kann der Scrum Master gemeinsam mit Stakeholdern die Ursachen für permanenten Scope Change bearbeiten, was auch immer diese sein mögen.
Das Konstrukt Sprint wird hier als strategisches Instrument verwendet und ist nicht nur Träger des Scopes.
Die optimale Sprintlänge
Wenn Sie mich fragen, ist die optimale Länge eines Sprints nicht zwei Wochen, sondern nur eine Woche.
Nicht nur, weil die Gefahr von teuren Scope-Changes hier am geringsten ist, sondern aus einer Reihe von weiteren Gründen:
Scrum ist eine schwierige Angelegenheit keine Frage. Wir sollten also alle Hilfen nutzen, um uns die Sache nicht noch schwieriger zu machen, sondern einfacher. Eine Woche können wir besser überblicken und damit besser planen, weil wir seit Kindesbeinen an so sozialisiert sind. Wir kennen den Wochenrhytmus quasi seit unserer Geburt und daher fällt es uns auch relativ leicht, den Zeitraum von einer Woche ziemlich präzise zu planen.
Storys müssen in einen Sprint passen. Je kürzer der Sprint ist, desto kleiner müssen auch die Storys sein. Ich habe viele Teams gesehen, die völlig genervt sind, von Product Ownern, die es lieben Mammut-Stories zu schreiben. Extremfälle von zwei Storys für einen dreiwöchigen Sprint mit einem siebenköpfigen Team, alles schon gesehen. Kurze Sprints zwingen die PO‘s kleine Storys zu schreiben.
Ich habe zudem oft Teams gesehen, die in der ersten Woche des zweiwöchigen Sprints die Sache ziemlich relaxed angehen, nach dem Motto „wir müssen ja erst nächste Woche liefern“. In der Tat, die Sprintlänge beeinflusst sogar die Velocity von Teams.
Kürzere Sprints, kürzere Meetings, mehr Wertschöpfungszeit
Die Vorliebe für längere, mindestens zweiwöchige Sprints beruht meist auf der irrigen Annahme, dass in längeren Sprints weniger Zeit für Meetings (Planning, Review, Retrospektive) verlorengeht und mehr netto Wertschöpfungszeit übrig bleibt.
Meine Erfahrung sagt eher das Gegenteil.
Lange Sprints zu planen dauert länger und ist deutlich ermüdender.
Scrum.org sagt, ein Planning für einen vierwöchigen Sprint darf bis zu 8 Stunden dauern. Mal im Ernst, wer möchte 8 Stunden in einem intensiven fachlich/technischen Workshop sitzen, bzw. wer erwartet ernsthaft, dass da etwas Sinnvolles bei rauskommt?
In kurzen Sprints sind die Meetings zwar häufiger, dafür aber sehr viel kürzer.
Eine Retrospektive kann man z.B. trotzdem alle zwei Wochen machen. So viel gibt es eh nicht jede Woche zu verbessern, bzw. um signifikante Dinge zu verbessern braucht es oft mehr Zeit.
Die Mission ist, aus einem 5 tägigen Sprint, 4,5 Tage netto Entwicklungszeit herauszukitzeln. Und das geht.
Tatsache ist, dass kürzere Sprints noch mehr Transparenz schaffen und noch mehr Disziplin einfordern. Anders kommt man eben nicht zu 4,5 Tagen Netto Wertschöpfungszeit.
Aber genau das ist es, was Teams oft nicht so gerne mögen. Ich habe oft gesehen, dass Dev-Teams und PO‘s ganz gerne auf Distanz bleiben und nicht das allerbeste Verhältnis pflegen. Bei kurzen Sprints müssen sie öfter und direkter miteinander kommunizieren.
Auch der Scrum Master muss intensiver mit dem Team arbeiten, um den Takt kurz zu halten.
Eigentlich ist es ja genau das, was wir in Scrum wollen.
