Nach dem Product-Backlog-Meeting steht das erste Sprint-Planning-Meeting auf der Agenda. Erster Punkt dort ist die Definition der Dauer eines Sprints. Auf den ersten Blick scheint die Sache ganz klar zu sein: Ein Sprint in Scrum dauert in der Regel 30 Tage. Doch das ist logischerweise nur eine Empfehlung. Abhängig vom Projekt und vom Team kann die Sprintlänge variieren. Es gibt Teams, die mit Sprints von ein oder zwei Wochen Länge arbeiten, andere wiederum bevorzugen bis zu sechs Wochen.

Wonach richtet sich also die Sprintlänge? Ganz einfach: Am Ende jedes Sprints muss ein „shipable Product“, also ein auslieferungsfähiges Produkt stehen. Das wiederum ist aber nicht zu verwechseln mit dem „fertigen“ Produkt. Es geht nur darum, dass ein bestimmtes, funktionierendes Featureset einsatzbereit ist. Egal, wie grundlegend seine Funktionalität ist.

Dementsprechend hängt die Sprintlänge also von der Größe und den Fähigkeiten des Teams ab, sowie von den User-Stories, sprich den zu verwirklichenden Features. Eine Website wird beispielsweise eher in kürzeren Sprints zu bewerkstelligen sein. Ein komplexes Produkt, bei dem komplizierte Entwicklungsprozesse und umfangreiche Vorarbeiten und Learnings nötig sind, wird eher in längeren Sprints angegangen werden.

Ein weiterer, nicht zu vernachlässigender Aspekt der Sprintlänge ist der damit verbundene Overhead. Je kürzer der Sprint, desto häufiger fallen beispielsweise die obligatorischen Sprint-Planning- und Sprint-Review-Meetings an. Gerade bei größeren Teams ist der damit zusätzlich verbundene Aufwand nicht zu unterschätzen.

Grundsätzlich aber gilt: Die Länge des Sprints wird weder vom Management, noch vom Product-Owner vorgegeben. Vielmehr bestimmt sie das Team selbst. Schließlich ist das ja einer der Scrum-Grundgedanken: Das Team weiß am besten, wie es die gestellten Aufgaben bewerkstelligen kann. Bei meinem kleinen und übersichtlichen Projekt hat sich das Team für einwöchige Sprints entschieden.