Die „richtige“ Sprintlänge

Donnerstag, 11. März 2010 von  
unter Fachartikel Scrum

Eine Frage, vor der alle Scrumteams schon mal standen ist: wie lang soll die Sprintlänge sein?
Was durch die Bank hinweg die gesamte Scrumliteratur vorschreibt ist, dass die Länge der Sprints zumindest über einen gewissen Zeitraum hinweg fix sein soll. Die Länge der Sprints will damit also im Vorhinein schon mal gut überlegt sein.

Stöbern wir durch die Bücher von Ken Schwaber oder durch verschiedene Artikel von Jeff Sutherland, dann stoßen wir da meist auf eine vorgeschlagene Länge von 30 Tagen. Bei Schwaber wird es nicht genauer erklärt, aber ich vermute mal, dass er mit diesen 30 Tagen einfach auf einen Kalendermonat abzielt, also ca. vier bis fünf Wochen und nicht auf 30 Werktage, was sechs Wochen ergeben würde. Etwas weiter geforscht ergibt sich aber scheinbar ein allgemeiner Konsense bei der Aussage, ein Sprint sollte zwischen einer bis vier Wochen lang sein.

Aber was bedeutet das jetzt für uns, wenn wir unser Projekt neu aufsetzen und die Sprintlänge festlegen wollen? Wann nehmen wir eine Woche? Wann vier? Und wann irgendwas dazwischen? Damit wollen wir uns in diesem Artikel befassen.

Rufen wir uns erstmals in Gedächtnis zurück, warum wir in Scrum überhaupt mit Iterationen arbeiten: Wir wollen in einem definierten Zeitraum ein in sich sinnvoll abgeschlossenes Ergebnis erreichen, das sogenannten potentiell auslieferbaren Produktinkrement.
Vielen Neueinsteigern in Scrum fällt es schwer, sich vorstellen zu können innerhalb einer Woche ein sinniges in sich abgeschlossenes Produktinkrement erstellen zu können. Dadurch geht die Tendenz eher zu längeren Sprints. Gleichzeitig scheinen sich aber mittlerweile in vielen Unternehmen die Prioritäten von Anforderungen im Stundentakt zu ändern, meist weil ständig neue und natürlich wichtigere-wie-alles-andere Anforderungen auftauchen. Die manchmal fast schon panisch anmutende Angst, irgendwelche Markttendenzen verpassen zu können und deshalb möglichst innerhalb von Stunden auf neue Erkenntnisse oder Vermutungen reagieren zu wollen, kann Projektverantwortliche schon mal in den Wahnsinn treiben und drückt die angestrebte Sprintlänge wieder nach unten.

Wir sehen uns scheinbar einem Zielkonflikt gegenüber und das alleine macht schon deutlich, dass es auf die Frage der richtigen Sprintlänge keine Pauschalantwort gibt.

Versuchen wir die Faktoren mal einzeln zu betrachten, sodass jeder von Ihnen die Möglichkeit hat, seine aktuelle oder zukünftige Projektsituation unter den einzelnen Gesichtspunkten zu bewerten.

Fangen wir mit der Frage an, was bedeutet eine möglichst kurze Sprintlänge für ein Projekt?
Zuerst fällt positiv auf, dass wir mit einer kurzen Sprintlänge auch eine recht kurze Reaktionszeit auf geänderte Anforderungen haben. Wenn wir die Regeln von Scrum hart spielen und der Sprint damit gegen Änderungen von außen geschützt ist, dann beträgt die durchschnittliche Reaktionszeit auf geänderte Umstände die Hälfte der Sprintlänge. Bei einer Sprintlänge von einer Woche also 3 ½ Tage.
Als nächstes Sticht der Umstand ins Auge, dass in einen kurzen Sprint natürlich auch nur entsprechend wenige Anforderungen passen und diese außerdem auch entsprechend klein sein müssen. An der Bewertung, ob dies positiv oder negativ ist, scheiden sich die Geister und es hängt auch von den Projektumständen ab. Es mag tatsächlich Projekte geben, in denen Anforderungen nicht auf die erforderliche Maximalgröße runter gebrochen und dann noch isoliert voneinander umgesetzt werden können. Objektiv ist das allerdings wirklich nur selten der Fall.
Eine kurze Sprintlänge zwingt den Produkt Owner und das Team auf jeden Fall zu einer klaren Fokussierung auf ein oder maximal zwei Ziele pro Sprint, weil ansonsten in der kurzen Zeit vermutlich keine in sich sinnvoll abgeschlossenen Features zu realisieren sind. Dementsprechend sind auf den Sprint Reviews auch selten die großen Würfe zu erwarten, dafür aber ständig neue Verbesserungen, Erweiterung, neue Features. Bei kurzen Intervallen wirkt dies wie ein kontinuierlicher Strom an Fortschritt.

Eher anspruchsvoll um nicht zu sagen schwierig ist bei kurzen Sprintlängen jedoch die Entwicklung einer größeren und investitionssicheren Systemarchitektur. Hier steigen die Anforderungen an gute Architekturvorgaben und an einen sauberen Programmierstil, wenn die Systemarchitektur nicht jede Woche neu erfunden oder völlig aus dem Runder laufen soll. Dementsprechend müssen hierfür im Team auch die entsprechenden Skills vorhanden sein oder bewusst aufgebaut werden. Darüber, wie auch in kurzen Sprints saubere Architektur entstehen und erhalten bleiben kann und was dafür notwendig ist, werde ich in einem anderen Artikel schreiben, wenn wir uns mit inkrementeller Architektur befassen.

Das führt uns direkt zur Betrachtung von langen Sprintlängen. Welche Auswirkungen haben diese auf ein Projekt?
Wenn wir bei einer kurzen Sprintlänge die kurze Reaktionszeit gelobt haben, dann ist sofort klar, dass dies bei langen Sprintlängen nicht mehr so ist. Bei einer Sprintlänge von vier Wochen beträgt die durchschnittliche Reaktionszeit jetzt schon 2 Wochen! Dass kann Stakeholder mit vermeintlich dringenden Begehren schon mal ein bisschen ungeduldig werden lassen.
Umgekehrt bietet die lange Sprintdauer aber auch viel Raum für Anforderungen. Dass soll aber dennoch nicht davon ablenken, dass auch hier klare Sprintziele mit Schwerpunkten für jeden einzelnen Sprint gesetzt werden sollen. Bitte behalten Sie das im Auge, die Gefahr ist sonst groß, dass sich das Team bei der Umsetzung der Anforderungen verzettelt und durch den fehlenden Fokus viel an Energie verloren geht.
Die kurzen Sprints erfordern, das Anforderungen knapp und knackig sein müssen, um in die Sprints zu passen und dafür müssen sie ziemlich präzise beschrieben sein, damit überhaupt abgeschätzt werden kann, ob sie in einen Sprint passen. Die langen Sprints verleiten leicht dazu, diese Präzision zu vernachlässigen, da die Anforderung schon irgendwie passen wird. Das rächt sich aber relativ schnell und deshalb muss auch bei langen Sprints die gleiche Sorgfalt auf die präzise Beschreibung der Anforderungen gelegt werden. Zumindest für die Anforderungen, die in einen Sprint eingeplant werden sollen.
Viel Platz für Anforderungen bedeutet aber auch die Möglichkeit, größere zusammenhängende Teile der Systemarchitektur in einem Stück planen und umsetzen zu können. Es ist also leichter, die Systemarchitektur aufzusetzen und Grundlagen zu schaffen. Und natürlich ist es ein schönes Gefühl in jedem Sprint Review nicht bloß ein zwei Kleinigkeiten sondern gleich einen großen Batzen an Neuerungen im Produkt zeigen zu können. Das dafür aber auch nur alle vier Wochen.

Hm, alles recht interessante Gesichtspunkte, aber so zwingend hilft das noch nicht weiter, zumindest nicht in allen Fällen. Betrachten wir ein paar einzelne Gesichtspunkte etwas genauer.

Bei kurzen Sprintlängen stellt sich die Frage des Overheads bzgl. der Meetings. Wir erinnern uns, in Scrum haben wir mit dem Sprint Planning, dem Sprint Review und der Sprint Retrospektive drei Regelmeetings, die einmal pro Sprint abgehalten werden. Bei einwöchigen Sprints wären das zwischen 12 und 15 Meetings im Monat, bei vierwöchigen Sprint halt genau 3. Klingt erst mal nach erheblichen Overhead bei kurzen Sprints. Allerdings darf man nicht vergessen, dass bei kurzen Sprints auch die Meeting wesentlich kürzer sein können, da ja nur der Inhalt einer wesentlich kürzeren Zeitperiode besprochen werden muss. Sollten Sie in Ihrem Team die Disziplin haben, Meetings nicht länger zu gestalten, wie wirklich notwendig ist, dann ist die höhere Anzahl an Meetings pro Monat kein Hinderungsgrund für kurze Sprintlängen. Ufern bei Ihnen jedoch Besprechungen grundsätzlich aus ohne dass Sie das einschränken können, dann wäre eher eine längere Sprintdauer zu empfehlen, bei der Sie dann weniger Meetings pro Monat haben.

Ein Punkt, den wir schon angesprochen hatten ist die Reaktionszeit auf Änderungen in den Anforderungen bzw. die Neupriorisierung von Anforderungen. Ich glaube ich habe es mal in einem der Bücher von Ken Schwaber gelesen, die entscheidende Frage bezüglich der Sprintlänge war: Wie lange kann der Product Owner den Mund halten? Übersetzt bedeutet das, wie lange kann der Product Owner das Team vor der Einflussnahme durch Stakeholder schützen? Wenn die Geschäftsführung regelmäßig neue Ideen ausbrütet, die natürlich immer wichtig sind und deshalb aus Sicht der Geschäftsführung immer sofort gemacht werden sollen, wie lange kann der Product Owner diese Stakeholder bremsen beziehungsweise wie viel Geduld und Verständnis für die Belange des Softwareentwicklungsprozesses bringen die einflussreichsten Stakeholder auf. Ist es diesen Stakeholder verständlich zu machen, dass neue Ideen und Anforderungen nur alle vier Wochen in Angriff genommen werden können oder bestehen die Stakeholder trotz aller Erklärungen auf möglichst sofortige Berücksichtigung ihrer Anforderungen?

Und jetzt zum nächsten Knackpunkt.
Es ist ja schön, wenn wir in der Lage sind Anforderungen in kleine, voneinander unabhängige und präzise beschriebene Pakete zu zerlegen, unsere Meeting kurz und effizient zu halten und auch trotz kürzester Sprintlänge eine vorbildliche Systemarchitektur planen und aufbauen zu können. Wert hat das Ganze aber nur dann, wenn am Ende jedes Sprints ein potentiell auslieferbares Produktinkrement entsteht und dazu gehört nach den Definitionen von Scrum auch, dass der produzierte Code getestet ist. Natürlich ist jedes Team selber für seine „Definition of done“ verantwortlich und damit kann der Anspruch, was als potentiell auslieferbar gilt natürlich auch beliebig weit nach unten gedrückt werden. Aber sinnvoll ist das nicht! Bei der Wahl der Sprintlänge ist also auch zu berücksichtigen, in welchem Zeitraum neue Funktionen sinnvoll getestet werden können. Ein möglichst hohes Maß an Testautomatisierung und eine ständig verfügbare Test- und Integrationsumgebung verkürzen den notwendigen zeitlichen Aufwand und ermöglichen so kürzere Sprintlängen. Aber überall da, wo manuelle Test notwendig oder Testumgebungen nicht ständig verfügbar sind (aus welchen Gründen auch immer), überall da ist bei der Planung der Sprintlänge zu berücksichtigen wann die für die Test erforderlichen Ressourcen zur Verfügung stehen. Idealerweise sind Tester aus der Fachabteilung fester Bestandteil des Teams und zu 100% für diese Tätigkeit eingeplant, aber wo sind die Bedingungen für ein Projekt schon ideal. Wenn mir meine Tester nur alle vier Wochen für jeweils fünf Tage zur Verfügung stehen, dann kann ich keine zweiwöchigen Sprints fahren, denn wie will ich im jeweils zweiten Sprint testen?
Das Gleiche gilt auch für das Sprint Review. Inhalt des Sprint Reviews ist es, dem Product Owner und den Stakeholdern die Ergebnisse des Sprints zu präsentieren. Dabei geht es dem Team nicht bloß darum, sich im Lichte seiner Leistungen zu sonnen, obwohl das natürlich auch schön ist. Nein, ein wichtiges Ziel des Sprint Reviews ist das direkte Feedback von Product Owner und Stakeholder darüber, ob die neuen Funktionen oder Korrekturen in Art und Umfang dem entsprechen, was sich die Stakeholder vorgestellt hatten oder auch nicht. Dieses Feedback ist wichtig für die ständige Verbesserung des Entwicklungsprozesses und auch für evtl. Kurskorrekturen bei der Priorisierung der nächsten Anforderungen. Bei einer einwöchigen Sprintdauer bedeutet das aber auch, dass jede Woche zumindest einige Stakeholder die Zeit für das Sprint Review haben müssen. Ist das dauerhaft nicht der Fall, dann ist fraglich ob die einwöchige Sprintlänge wirklich Sinn macht.

Ein in meinen Augen eher kosmetischer Punkt, den wir hier aber dennoch nicht verschweigen wollen sind die Auswirkungen der Sprintlängen auf die Schwankungen in der Velocity eines Teams. Um sowohl für die Planung der nächsten Sprints wie auch für die grobe Releaseplanung eine Vorstellung über die zukünftige Entwicklungsgeschwindigkeit zu haben, halten wir für jeden abgelaufenen Sprint die Anzahl der erledigten Aufwände fest. Das können Story Points sein oder auch ideale Tage oder Gummibärchen, wie wir sie in meinem aktuellen Projekt gerne nennen. Daraus bilden wir einen Chart, der uns die Entwicklung der Entwicklungsgeschwindigkeiten graphisch aufbereitet und uns eine Prognose für die zukünftige Entwicklungsgeschwindigkeit ermöglichen soll.
Jetzt ist aber zu beachten, dass ein plötzlicher Ausfall eines Mitarbeiters für einen Tag, z.B. durch Krankheit, die Velocity eines kurzen Sprints wesentlich stärker beeinflusst wie die eines langen Sprints. Und bei langen Sprints besteht auch eine größere Wahrscheinlichkeit, dass in jedem Sprint mal jemand überraschend einen Tag ausfällt. Das heißt, die Velocity wird in längeren Sprints eher gleichmäßiger ausfallen als in kurzen.

Spielt das eine Rolle? Ich denke nicht. Auf dem Chart sehen die vermutlich stark unterschiedlichen Entwicklungsgeschwindigkeiten bei kurzen Sprintlänger zwar etwas wild aus, für die Berechnung eines Trends ergeben sich aber keine echten Unterschiede. Dieser Punkt ist also eindeutig zu vernachlässigen.

Kommen wir zurück zum Anfang, unserer Problemstellung, wie lang soll die Sprintlänge für unser neues Scrumprojekt sein. Sind wir da wirklich weitergekommen? Vielleicht ja. Möglichweise ist einer der Umstände, die wir gerade beschrieben haben der Schlüsselfaktor. Die schnelle Reaktionszeit, die unsere Stakeholder von uns verlangen oder die fehlenden Testkapazitäten. Dann kann daran die, ich nenne sie mal „initiale“ Sprintlänge festgemacht werden. Wenn aber keiner dieser Faktoren so deutlich ins Auge sticht oder einfach noch nicht bekannt ist, nun dann trifft man einfach eine Annahme und startet damit.

Ich hatte am Anfang davon gesprochen, dass die Sprintlänge zumindest über einen gewissen Zeitraum hinweg fix sein soll. Hintergrund ist, dass damit ein gewisser Flow geschaffen werden soll, in dem sich hilfreiche Abläufe einschleifen und den Entwicklungsprozess einfach und stabil halten sollen. Bei jedem Sprint die Dauer des Sprint zu ändern, würde dem im Wege stehen. Das bedeutet aber eben nicht, dass die Dauer der Sprints einmal festgelegt wird und dann nie wieder verändert werden darf. Scrum ist eine agile Methodik und einer der Grundpfeiler ist und bleibt „inspect and adapt“ und das gilt auch für die Sprintlänge. Einfach mal mit was starten, sehen wie es läuft und bei Bedarf anpassen.

Meine Empfehlung für die ersten Sprints: Wenn das Team neu in Scrum ist oder die Skills für inkrementelle Architektur nicht vorhanden sind oder das Testen größtenteils noch manuell erfolgt und auch andere Faktoren im Testen noch nicht optimal sind, dann als initiale Sprintlänge vier Wochen wählen. Dabei aber kontinuierlich daran arbeiten, die Bedingungen für kürzere Sprintzeiten zu verbessern, d.h. die Grundlagen in inkrementeller Architektur zu schaffen, die Tests zu automatisieren, ständig verfügbare Testumgebungen aufzubauen und so weiter. Und dann nach und nach die Sprintlängen alle paar Monate um eine Woche zu reduzieren. Dabei ist für mich persönlich der Einwochensprint nicht zwingend das Endziel. In vielen Fällen pendeln sich Scrumprojekte bei einem Zweiwochenzyklus ein, das scheint ein guter Kompromiss zwischen den beiden Extremwerten zu sein. Aber schussendlich muss jedes Projekt seinen eigenen Zyklus finden.

Kommentare

Einen Kommentar hinzufügen...

Sie müssen registriert und angemeldet sein um einen Kommentar zu schreiben.