Unterschiedliche Sprintlängen (und welche Auswirkungen es hat)

Sprintlängen
Von Sebastian Schneider // 08.08.2021 // 0 Kommentare

Unterschiede in Sprintlängen werden oft doppeldeutig zu verstanden. Zum einen wird damit beschrieben, dass sich die Sprintlängen in einem Scrum Team ändern und damit von Sprint zu Sprint unterschiedlich lang sind. Zum anderen wird damit aber auch gemeint, das mehrere unterschiedliche Teams eine konstante, aber zwischen den Teams unterschiedliche Sprintlänge verwenden.

Zuerst starten wir mit dem Verständnis, schauen uns dann die verschiedenen Optionen an und betrachten abschließend die die Auswirkungen.

Was ist eine Sprintlänge?

Klären wir zunächst, was eine Sprintlänge genau ist. In Scrum nutzen wir den Sprint als Herzschlag eines jeden Teams oder gar der Organisation. Bleiben wir bei Scrum, dann darf der Sprint maximal einen Monat lang Zeit in Anspruch nehmen. Blicken wir zum Beispiel nur auf das agile Manifest, dann finden wir weichere Angaben.

Grundsätzlich können wir festhalten, dass wir in Scrum einen Zeitabschnitt definieren, der immer gleichlang ist und den nennen wir Sprint. Durch die Dauer dieses Zeitabschnitts ergibt sich dann auch die Sprintlänge.

Scrum

Nutzt du Scrum, dann ist deine Sprintlänge maximal einen Monat, in der Regel aber kürzer. Aus meiner Praxis kann ich sagen, dass die meisten immer zwei oder drei Wochen gewählt haben. Doch auch hier sind andere Werte denkbar. Damit kommst du sofort auch zur Länge deines Sprints - also recht einfach und keine Raketenwissenschaft.

Agiles Manifest

Das agile Manifest ist etwas großzügiger und erlaubt und erlaubt uns folgendes:

Agiles Manifest  - agilemanifesto.org

Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.

Damit bist du etwas freier deine Länge auszuwählen, solltest sie natürlich nicht zu lang werden lassen. Bei der agilen Entwicklung wollen wir gerade ja darauf fokussieren, dass wir häufiger in kleineren Chargen liefern.

Eigenbau

Natürlich kannst du auch eigene Kreationen gewählt haben. Darauf gehe ich hier nicht weiter ein, aber je nachdem, was für dich relevant ist, hast du vielleicht eine ganz andere Lösung gefunden. Zur Vollständigkeit sei es deshalb hier noch mal erwähnt.

Unterschiedliche Sprintlängen

unterschiedliche Sprintlängen

Jetzt schauen wir uns einmal die typischen Situationen an, bei denen eine Sprintlänge unterschiedlich sein kann. Die folgenden Optionen wirst du sehr wahrscheinlich vorfinden können, auch wenn sie nicht abschließend umfassend sein müssen.

Das Scrum Team ändert die Sprintlänge

Wenn das Scrum Team die Sprintlänge ändert, dann passiert das in der Regel aus zwei Gründen. 

  • Entweder hat ein Scrum Team gelernt und nun besser verstanden, warum die eine Sprintlänge nicht mehr den eigenen Ansprüchen genügt. Aus einer Reflexion wurde deshalb beschlossen, dass eine Änderung benötigt wird. Dabei wird nun eine neue Sprintlänge gewählt, die konstant in den folgenden Sprints angewendet wird.
  • Es kann auch sein, dass das Scrum Team durch Unwissenheit im Team bzw. durch Unwissenheit von außen (z.B. der Organisation) in wechselnde Sprintlängen gezwungen wird. Dann sind die Sprintlängen häufig wechselnd. Dabei basiert das nicht auf dem Lernen, sondern auf Unverständnis. So etwas siehst du sehr oft, wenn du ganz unterschiedliche Rhythmen in kurzer Zeit bei den Teams findest, z.B. : 1 Woche, 1 Woche, 2 Wochen, 1,5 Wochen, 4 Wochen, ...

Wenn du regelmäßig oder oft die Sprintlänge in deinem Team änderst, dann wirst du viel Kraft von Scrum verlieren. Dann passiert es nicht selten, dass Schätzungen ihren Wert verlieren, die Velocity sinkt und natürlich werden auch empirische Erfahrungen schwieriger, da dir der zeitliche, konstante Kontext fehlt. Gerade die regelmäßigen Sprintlängen geben uns im Scrum Team die Möglichkeit regelmäßig zu inspizieren und zu adaptieren.

Mehrere Teams arbeiten mit unterschiedlichen, aber gleichbleibenden Sprintlängen

Wenn du in der Scrum Skalierung den Fall der unterschiedlichen Sprintlängen betrachtest, dann wirst du auf Frameworks stoßen wie das Large Scale Scrum (LeSS) oder auch das Nexus. Während zum Beispiel das erste nur eine Sprintlänge für die gesamte Organisation kennt, ist das Nexus liberaler und schließt das vorab nicht aus.

Nimm zum Beispiel eine Hardwareentwicklung und eine Softwareentwicklung. Beide Domänen brauchst du für dein Produkt. Eine Umsetzung könnte nun so aussehen, dass die Hardwareentwicklung immer längere Sprintlängen hat und die Software kürzere. Während die Software selbst schon neue Versionen (auf ein oder derselben Hardwareversion) erstellt, wird eine Hardwareversion nur in längeren Sprintzyklen zur Verfügung gestellt.

Zu einem bestimmten Zeitpunkt - meist, wenn die Sprintlängen gleich zu einem gemeinsamen Ende führen - wird dann gemeinsam integriert und alle notwendigen Dinge für das Produkt zu einem Inkrement zusammengetragen.

Unterschiedlichen Sprintlängen in der Praxis

Auch wenn ich selbst sehr den Ansatz mag, alles im gleichen Takt (also Sprintlänge) zu orchestrieren, gibt es Umstände im Team, in der Organisation, die das (noch) nicht zu lassen. Im Folgenden schauen wir einmal auf ein paar typische Auswirkungen, die sich so oder so ähnlich finden lassen.

Velocity ist leider nicht linear

Aus der Erfahrung kann ich sagen, dass die Velocity nicht linear ist. Ändert sich die Länge von einem Sprint um 7 Tage, bedeutet das nicht, dass die Velocity sich auch um diesen Faktor sich ändert. Sie kann einbrechen oder sich anderweitig komisch verhalten. So sind oft wechselnde Sprintlängen meist sehr kontraproduktiv. Das Team tut also immer gut daran, sich sehr genau zu überlegen, ob ich eine neue Sprintlänge brauche. Die ist dann auch erstmal fest, bis ausreichend Daten zum Lernen gesammelt worden.

Es erzeugt Unruhe

Es ist spannend, wenn man zusehen kann, was eine häufige Änderung der Sprintlänge im Team für Unruhe erzeugen kann. So verändert sich die Frequenz der Meetings, Abstände werden kürzer und Menschen kommen aus dem Takt. Auch das ist für mich ein wichtiger Punkt für konstante Sprintlängen.

Lernen wird schwieriger

Wenn wir feste Sprintlängen haben (oder selten gewechselte Längen), dann fällt das Lernen durchaus leichter. Man kann viele Beobachtungen auf einen festen Zeitabschnitt mappen und damit auch gut vergleichen.

Risiko steigt

Wenn wir in einem skalierten Kontext die Sprintlängen über mehrere Teams entkoppelt, dann kann es zu einem erhöhten Risiko führen, gerade wenn wir nicht gemeinsam integrieren. Denn wenn das eine Team mehrfach neue Versionen erzeugt und schon weiter ist, als das andere - dann steigt das Risiko, dass die Stände nicht zusammenpassen.

Entkopplung hilft

Gerade wenn wir nach Scrum ein Produkt bearbeiten wollen, in dem wir Hardware und Software in einem Produkt haben, kann es helfen eine gewisse Entkopplung durchzuführen. Die Software ist schneller als die Hardware und erzeugt häufiger neue Versionen auf ein und der gleichen Hardwareversion. Wenn sich die Hardwareversion dann ändert (in einem längeren Takt), dann nutzt die Software ebenso diesen neuen Stand und entwickelt dann erneut weiter, bis zur nächsten Hardwareaktualisierung.

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

>