Warum Sprints und wie lang sollten sie sein?

Einer der integralen Bestandteile von Scrum ist der iterative Entwicklungsprozess mit seinen festgelegten Zeitintervallen, den Sprints. In vielen Projekten wird die aktuell festgelegte Sprintlänge von den Projektbeteiligten regelmäßig in Frage gestellt. Um in dieser Diskussion die Vor- und Nachteile der unterschiedlichen Sprintlängen zu beurteilen, betrachte ich zunächst die unterschiedlichen Gründe und möglichen Randbedingungen für das iterative Vorgehen.

Iterationen in einem Vorgehensmodell bedeuten ein mehrfaches Durchlaufen derselben Vorgehensschritte. Dies kann sowohl zeitgesteuert (alle n Wochen), als auch ereignisgesteuert organisiert sein. Dabei können sich unterschiedliche Arten von Iterationen überschneiden oder aufeinander aufbauen. In Scrum z.B. teilen sich große zeitgesteuerte Iterationen (Sprints) sowohl in ereignisgesteuerte (jedes abgeschlossene Backlog Item), als auch in mehrere kleine zeitgesteuerte (Tage mit Daily Standups) auf. Meist hat man noch einen Produktionsreleaseszyklus, der sich aus mehreren Entwicklungssprints zusammensetzt.

Das iterative Vorgehen in agilen Entwicklungsprozessen findet man in den 12 Prinzipien des Agilen Manifest wieder. Dabei weisen die folgenden drei Prinzipien darauf hin:

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Aus den Prinzipien lassen sich drei grundlegende Ideen für das iterative Vorgehen aufzeigen:

• Regelmäßige Reflektion des Entwicklungsprozesses
• So früh wie möglich Software produktiv einsetzen und dann inkrementell erweitern
• Stakeholdern regelmäßig laufende Software präsentieren

Für diese drei Ideen können unterschiedliche Iterationssteuerungen, welche  sowohl unabhängig von der Art (Zeit/Ereignis) als auch von den Parametern (1 Tag/4 Wochen) sind, verwendet werden.

Die regelmäßige Reflektion des Entwicklungsprozesses dient der Verbesserung und Anpassung des Prozesses an die aktuellen Gegebenheiten. In den meisten Projekten besteht dabei die Gefahr, dass dies durch den projekttypischen kurzfristigen Zeit- und Erfolgsdruck vernachlässigt wird. Daher ist es sinnvoll, in festen Zeitintervallen den notwendigen Freiraum dafür zu reservieren. Scrum arbeitet hier zweistufig: täglich wird ein Teil des Standup-Meetings genutzt und nach jedem Sprint findet ein dediziertes Retrospektiven-Meeting statt.

Dass die zu entwickelnde Software so früh wie möglich produktiv eingesetzt wird, dient erst einmal wirtschaftlichen Gründen. Der iterative Produktionsgang startet die Wertschöpfung der Software schon nach dem ersten Schritt. Weiterhin bietet es die Chance ein gegebenes „Window of opportunity“ zu treffen, das ohne das schrittweise Vorgehen nur schwer umsetzbar wäre (siehe hierzu auch „Der Business Case für Agilität“ ). Ein weiterer, nicht zu unterschätzender, Punkt ist das Feedback aus dem produktiven Einsatz. Dieses ist entschieden wertvoller als das Feedback über die laufende Software in einer Sandkastenumgebung (siehe unten). In vielen Umgebungen bedeutet ein produktives Release jedoch jede Menge organisatorischen und technischen Aufwand. Dabei kann es sich unter anderem um die Übergabe an den Betrieb, die Schulung von Benutzern oder das Anpassen von Vertriebs- und Marketingmaterial handeln. Auch die umgesetzten Features müssen einen gewissen Umfang und eine gewisse Konsistenz haben. Daher werden produktive Releases oft in eher größeren Zyklen organisiert.

Um ein regelmäßiges und zeitnahes Feedback über den aktuellen Entwicklungstand zu bekommen, wird die laufende Software den Stakeholdern meist in einer Sandkastenumgebung präsentiert und zur Verfügung gestellt. Dies erfolgt häufiger als die Produktionsreleases und ermöglicht es den Stakeholdern, die Projektziele auf Grund des schon erreichten nachzujustieren.

Nach den agilen Prinzipien ist für den letzten Punkt keine zeitlich feste Iteration vorgegeben. Auch eine kontinuierliche Lieferung wäre denkbar, d.h. immer wenn ein Feature (oder sinnvolle Gruppe von Featuren) fertig ist, wird die laufende Software präsentiert und das nächste aus dem Backlog genommen. Hier zeigt sich schon die erste Schwierigkeit. Die Software soll ja gerade den Stakeholdern präsentiert werden, die nicht in die tägliche Projektarbeit eingebunden sind. Hier ist ein kontinuierliches Feedback auf Grund von Aufwand und Zeit (der Stakeholder) nicht wirtschaftlich. Sinnvollerweise fasst man daher mehrere „Features“ zusammen, um sie zusammen zu präsentieren. Bei der Terminfindung dieser Präsentationstermine bietet sich wiederum ein fester zeitlicher Rhythmus an, in dem der jeweils aktuelle Stand präsentiert wird.

Aus diesen Gründen ergeben sich zeitlich feste Iterationen. Scrum geht mit seinen Sprints aber noch weiter, in dem am Anfang jeder Iteration der geplante inhaltliche Umfang festgelegt wird. Aus meiner Sicht sprechen folgende Gründe für diese Vorgehen:

• Die Erfahrung in der Projektarbeit zeigt, das Deadline-Termine dabei helfen, sich gerade in der Endphase der Iteration auf die Fertigstellung einer Aufgabe zu konzentrieren.
• Da nur zum Ende der Iteration geliefert werden muss, ist gerade am Anfang kein großer Lieferdruck vorhanden, so dass Freiraum für Fragen zum Design und zur Architektur vorhanden ist.
• Durch die enge und intensive Einbeziehung von Stakeholdern in das Projekt besteht die Gefahr, dass die Entwicklungsarbeit durch eine erhebliche Menge an Änderungswünschen und Umpriorisierungen behindert wird. Durch die Festlegung des geplanten inhaltlichen Umfangs sind die enthaltenen Anforderungen für die Dauer der Iteration nur in extremen Ausnahmen änderbar und die aktuelle Entwicklungsarbeit wird nicht gestört.

Wie kann dies bei der Beurteilung von unterschiedlichen Sprintdauern in Scrum helfen?

Die genutzte Sprintdauer hat auf die dargelegten Gründe für die zeitlich festgelegten Iterationen mit geplanten Inhalten einen unterschiedlichen Einfluss:

Eine Verkürzung der Sprints erhöht den Aufwand (für Stakeholder und Team) für die Sprint Reviews. Ein Sprint Review, in dem auch Feedback von den Stakeholdern kommen soll, lässt sich nicht sinnvoll unter 90 Minuten reduzieren. Meist wird das von Seiten der Stakeholder dadurch ausgeglichen, dass sie seltener teilnehmen und so auch eine Diskussion zwischen den Stakeholdern seltener möglich wird.

Auf den ersten Blick hat die Sprintdauer keinen großen Einfluss auf den Fertigstellungsfokus, welcher durch die Deadline erzeugt wird. Aber gerade eine kurze Sprintdauer macht es schwerer, die Sprintinhalte zu planen. Die in Scrum durchgeführten Schätzungen sind meist fehlerhaft, was sich aber statisch über die Menge der Anforderungen ausgleicht. Je kleiner der Sprint, um so weniger Anforderungen werden geplant und um so stärker können die Fehler in der Schätzung durchschlagen. Daher wird bei kleinerer Sprintdauer die Deadline häufiger nicht eingehalten. Verstärkt wird dieser Effekt noch dadurch, dass sich bei kürzeren Sprints auftretende Schwierigkeiten, z.B. die mehrtägige Krankheit eines Teammitglieds, seltener ausgleichen lassen. Wird die Deadline aber regelmäßig nicht eingehalten, verliert sie schnell ihre fokussierende Wirkung.

Der gefühlte geringere Lieferdruck zu Beginn eines Sprints ist ebenfalls erst ab einer gewissen Sprintdauer vorhanden. Ein Freiraum von 2 bis 3 Tagen innerhalb eines 4-Wochen Sprints entspricht nur noch 4 bis 6 Stunden in einem einwöchigen. Gerade dieser Freiraum bietet auch einen gewisse mentale Erholung von Stress am Sprintende und trägt so zu einer konstante Arbeitsgeschwindigkeit über alle Sprints bei.

Beim Schutz vor Störungen gibt es zwei gegenläufige Effekte. Durch eine kürzere Sprintdauer, werden Änderungen durch Stakeholder früher berücksichtigt und ein gegebenenfalls auftretender Druck, die Änderung schon in einem laufenden Sprint wirksam werden zu lassen, ist geringer. Andererseits werden vom PO, formulierte Änderungen durch das Team in einem laufenden Sprint bewertet bzw. geschätzt. Längere Sprints erlauben es dem PO diese Änderungen länger zu sammeln und zu konsolidieren, bevor das Team sich damit befasst.

Die Auswahl der geeigneten Sprintdauer hängt von vielen unterschiedlichen Randbedingungen des Projektes ab. Eine generelle Regel kann man nicht aufstellen. Man sollte sich aber die Nachteile bei einer Änderung der Dauer vor Augen führen und gegen die Vorteile abwägen. Ich kenne erfolgreiche Projekte sowohl mit vierwöchigen, als auch mit einwöchigen Sprints.

Welche Erfahrungen habt ihr mit unterschiedlichen Sprintlängen gemacht? Seht ihr noch mehr Gründe für Sprints, statt einfach kontinuierlich zu liefern?