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
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.
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.
