Bei der Einführung von Scrum fragt man sich wie lang die Sprints sein sollen. Was sind eure Erfahrungen, wie lang soll denn ein Sprint sein?
1 Antwort
Ich finde, dass lässt sich nicht so pauschal beantworten, da es einige Faktoren gibt, die die Sprintlänge beeinflussen.
Ein wichtiger Aspekt dabei ist, die Häufigkeit an neuen Anforderungen von Kunden oder Stakeholdern und dabei die "Geduld", die aufgebracht wird, auf die Lieferung einer Auslieferung zu warten. Wenn sehr häufig neue Anforderungen kommen und die Anforderer sehr ungeduldig sind, empfiehlt sich eine kurze Sprintdauer, da das die Chance erhöht, dass das Team das Sprintbacklog stabil halten kann und nicht durch "Super wichtige VIP-Anforderungen" zum Scope Change "genötigt" wird.
Ein anderer Aspekt ist der Aufwand zur Erstellung einer Releaseversion, bzw. für ein Update beim Kunden. Wenn dies alles sehr Aufwendig ist, könnte es sinnvoll sein, eher einen längeren Sprint zu planen, um diesen Aufwand nicht zu häufig zu haben. Man könnte aber auch sagen, dass es gerade in einem solchen Fall sinnvoll ist, den "Schmerz" zu provozieren, damit man ihn lindert oder beseitigt. Damit müsste man auch in einem solchen Fall die Sprintlänge kürzer wählen. Das würde ich allerdings nur dann tun, wenn ich auch in der Lage bin am Aufwand etwas zu ändern.
Weiterhin kann auch die Erfahrung mit Scrum ein Anhaltspunkt für die Länge des Sprints sein. So habe ich mir angewöhnt zu Beginn einer Scrum Einführung Sprints mit einer Länge von einer Woche durchzuführen, damit man sich an die Rituale (Sprint Planning, Sprint Review, Retrospektive und Backlog Refinement) gewöhnen kann und darüber hinaus Erfahrungen mit der Erstellung von Anforderungen zu sammeln und schnell korrigieren zu können, wenn es nicht so läuft wie geplant. Dieses Vorgehen empfehle ich aber in der Regel nur für die ersten Wochen, da der Overhead für die Sprint-Wechsel-Meetings aus meiner Sicht in diesem Fall sehr hoch und daher nur kurzfristig sinnvoll ist.
In vielen Fällen ergibt sich aus diesen Gesichtspunkten eine Dauer von 2 Wochen, die häufig ein guter Kompromiss ist. Aber wie so oft, kommt es auf die Situation im Projekt an.
Ein wichtiger Aspekt dabei ist, die Häufigkeit an neuen Anforderungen von Kunden oder Stakeholdern und dabei die "Geduld", die aufgebracht wird, auf die Lieferung einer Auslieferung zu warten. Wenn sehr häufig neue Anforderungen kommen und die Anforderer sehr ungeduldig sind, empfiehlt sich eine kurze Sprintdauer, da das die Chance erhöht, dass das Team das Sprintbacklog stabil halten kann und nicht durch "Super wichtige VIP-Anforderungen" zum Scope Change "genötigt" wird.
Ein anderer Aspekt ist der Aufwand zur Erstellung einer Releaseversion, bzw. für ein Update beim Kunden. Wenn dies alles sehr Aufwendig ist, könnte es sinnvoll sein, eher einen längeren Sprint zu planen, um diesen Aufwand nicht zu häufig zu haben. Man könnte aber auch sagen, dass es gerade in einem solchen Fall sinnvoll ist, den "Schmerz" zu provozieren, damit man ihn lindert oder beseitigt. Damit müsste man auch in einem solchen Fall die Sprintlänge kürzer wählen. Das würde ich allerdings nur dann tun, wenn ich auch in der Lage bin am Aufwand etwas zu ändern.
Weiterhin kann auch die Erfahrung mit Scrum ein Anhaltspunkt für die Länge des Sprints sein. So habe ich mir angewöhnt zu Beginn einer Scrum Einführung Sprints mit einer Länge von einer Woche durchzuführen, damit man sich an die Rituale (Sprint Planning, Sprint Review, Retrospektive und Backlog Refinement) gewöhnen kann und darüber hinaus Erfahrungen mit der Erstellung von Anforderungen zu sammeln und schnell korrigieren zu können, wenn es nicht so läuft wie geplant. Dieses Vorgehen empfehle ich aber in der Regel nur für die ersten Wochen, da der Overhead für die Sprint-Wechsel-Meetings aus meiner Sicht in diesem Fall sehr hoch und daher nur kurzfristig sinnvoll ist.
In vielen Fällen ergibt sich aus diesen Gesichtspunkten eine Dauer von 2 Wochen, die häufig ein guter Kompromiss ist. Aber wie so oft, kommt es auf die Situation im Projekt an.
Die Idee mit Wochensprints bei Beginn einer Scrumeinführung kann ich unterstützen. Wir haben das damals auch so gemacht. Ziel der kurzen Sprintlänge war einfach ausgedrückt: Lernen, wie Scrum funktioniert. Erfahrungsgemäß gibt es eben gerade bei der Einführung sehr schnell viel Optimierungspotential bzw. -ideen. Damit diese zeitnah mittels den Retrospektiven umgesetzt werden können, dient eine kurze Sprintdauer sehr.