Scrum Sprint Länge: Warum 1 Woche effektiver ist

Was ist die optimale Scrum Sprint Länge? Die überraschende Erkenntnis: 1-wöchige Sprints sind effektiver! Lese hier warum.

Scrum Sprint Länge: Warum 1 Woche effektiver ist | scagile blog

Inhalt dieses Artikels

Der Sprint in Scrum

Scrum organisiert die Wertschöpfung in Iterationen, sogenannten Sprints. Sprints sind in Scrum zunächst einmal nichts anderes als Timeboxen, also einfach nur eine Zeiteinheit. Nicht mehr, aber auch nicht weniger.

Damit – und das ist der interessante Aspekt an Scrum – führt Scrum ein anderes Paradigma des Zeitmanagements ein.

Auch Wasserfall kennt bestimmte Phasen wie Spezifikationsphase, Implementierungsphase, Testphase, Dokumentationsphase, Abnahmephase, etc. Hier aber sind die Zeitabschnitte an bestimmten Content gebunden und der Content bestimmt letztlich die Länge des Zeitabschnittes. Die Phase ist beendet, wenn die Ziele dieser Phase erreicht sind bzw. zumindest zufriedenstellende Ergebnisse geliefert hat.

Scrum dreht das Verhältnis zwischen Timebox und Content genau um. Die Timebox, also die Länge des Sprints ist klar definiert und sollte sich möglichst selten ändern. Dazu kommen wir gleich noch

Warum ist die Sprintlänge so wichtig?

Variabel ist der Content, genauer der Scope, der in dieser Timebox geliefert werden soll.

Auf dem ersten Blick scheint dieser Paradigmenwechsel erforderlich zu werden wegen vertikaler (end-2-end) und featureorientierter Entwicklung, die Scrum einführt. Aber das Entkoppeln von Timebox und Scope eröffnet Scrum-Teams noch mehr Möglichkeiten.

Das Entkoppeln von Timebox und Scope eröffnet eine wesentlich größere Flexibilität. Bei der Wahl der Länge eines Sprints kann plötzlich auf andere Dinge Rücksicht genommen werden, als nur auf den Scope.

Die Sprintlänge wird damit mehr zu einem strategischen Instrument um den Flow von Value besser zu unterstützen. Folgendes Beispiel verdeutlicht das:

Welche Rolle spielen Scope Changes im Scrum Sprint?

Neben Bugs sind ständige Scope-Changes mitten im Sprint nicht nur ein Ärgernis von Scrum Teams, sondern sie sind vor allem sehr teuer und ein absoluter Velocity-Killer.

Crossfunktionale Teams haben sich während des Plannings, dass ja mit allen Aktivitäten zusammengenommen, mehrere Tage Aufwand (nicht Dauer) über alle Teammitglieder hinweg kostet, viel Mühe gegeben, einen Scrum Sprint perfekt auszubalancieren. 

Ein Scope-Change zerstört sofort diese Balance, ein Replanning ist notwendig und all das kostet.

Teams, die sich ständig Scope-Changes gegenübersehen, könnten die Länge der Sprints z.B. auf eine Woche verkürzen, gegebenenfalls auch nur für eine Phase

In der Zwischenzeit kann der Scrum Master gemeinsam mit Stakeholdern die Ursachen für permanenten Scope Change bearbeiten, was auch immer diese sein mögen.

Das Konstrukt Sprint wird hier als strategisches Instrument verwendet und ist nicht nur Träger des Scopes.

Priorisieren mit der WSJF-Methode [+ Excel Template].

Mit der WSJF-Methode wird die PI-Planung zum Kinderspiel und ist effektiver als je zuvor. Klicken Sie hier für die kostenlose Schritt-für-Schritt-Anleitung und die WSJF-Excel-Vorlage.

Die optimale Sprintlänge

Wenn Sie mich fragen, ist die optimale Länge eines Sprints nicht zwei Wochen, sondern nur eine Woche.

Nicht nur, weil die Gefahr von teuren Scope-Changes hier am geringsten ist, sondern aus einer Reihe von weiteren Gründen:

Eine Woche können wir besser überblicken und damit besser planen, weil wir seit Kindesbeinen an so sozialisiert sind.

Scrum ist eine schwierige Angelegenheit keine Frage. Wir sollten also alle Hilfen nutzen, um uns die Sache nicht noch schwieriger zu machen, sondern einfacher. Wir kennen den Wochenrhytmus quasi seit unserer Geburt und daher fällt es uns auch relativ leicht, den Zeitraum von einer Woche ziemlich präzise zu planen.

Storys müssen in einen Sprint passen.

Je kürzer der Sprint ist, desto kleiner müssen auch die Storys sein. Ich habe viele Teams gesehen, die völlig genervt sind, von Product Ownern, die es lieben Mammut-Stories zu schreiben. Extremfälle von zwei Storys für einen dreiwöchigen Sprint mit einem siebenköpfigen Team, alles schon gesehen. Kurze Sprints zwingen die PO‘s kleine Storys zu schreiben.

Die Sprintlänge beeinflusst sogar die Velocity von Teams.

Ich habe zudem oft Teams gesehen, die in der ersten Woche des zweiwöchigen Sprints die Sache ziemlich relaxed angehen, nach dem Motto „wir müssen ja erst nächste Woche liefern“.

Sprint Planning Backlog

Probiere scagile jetzt aus und siehe wie dein Sprint Backlog aussehen könnte.

Kürzere Sprints, kürzere Meetings, mehr Wertschöpfungszeit

Die Vorliebe für längere, mindestens zweiwöchige Sprints beruht meist auf der irrigen Annahme, dass in längeren Sprints weniger Zeit für Meetings (Planning, Review, Retrospektive) verlorengeht und mehr netto Wertschöpfungszeit übrig bleibt.

Meine Erfahrung sagt eher das Gegenteil.

Lange Sprints zu planen dauert länger und ist deutlich ermüdender

Scrum.org sagt, ein Planning für einen vierwöchigen Sprint darf bis zu 8 Stunden dauern. Mal im Ernst, wer möchte 8 Stunden in einem intensiven fachlich/technischen Workshop sitzen, bzw. wer erwartet ernsthaft, dass da etwas Sinnvolles bei rauskommt?

In kurzen Sprints sind die Meetings zwar häufiger, dafür aber sehr viel kürzer.

Eine Retrospektive kann man z.B. trotzdem alle zwei Wochen machen. So viel gibt es eh nicht jede Woche zu verbessern, bzw. um signifikante Dinge zu verbessern braucht es oft mehr Zeit.

Aber genau das ist es, was Teams oft nicht so gerne mögen. Ich habe oft gesehen, dass Dev-Teams und PO‘s ganz gerne auf Distanz bleiben und nicht das allerbeste Verhältnis pflegen. Bei kurzen Sprints müssen sie öfter und direkter miteinander kommunizieren.

Die Mission ist, aus einem 5 tägigen Sprint, 4,5 Tage netto Entwicklungszeit herauszukitzeln. Und das geht.

Tatsache ist, dass kürzere Sprints noch mehr Transparenz schaffen und noch mehr Disziplin einfordern. Anders kommt man eben nicht zu 4,5 Tagen Netto Wertschöpfungszeit.

Auch der Scrum Master muss intensiver mit dem Team arbeiten, um den Takt kurz zu halten.

Eigentlich ist es ja genau das, was wir in Scrum wollen .

Die App für scaled agile Teams ist da!

Klicke, um Artikel mit den gleichen Tags zu zeigen:

Klaus Riedel
Als agile Coach begleitete Klaus Riedel mit seinem Team die digitale Transformation und die Einführung von Scrum und SAFe in großen Organisationen wie Deutsche Bank, Conrad Electronics, Volkswagen, PWC und anderen.

Alle seine gewonnenen praktischen Erfahrungen in mehr als 15 Jahren agile Transformation sind in die Artikel seines Blogs eingeflossen.

In der Scagile Academy bildet er Nachwuchs Agile Experts aus und seit 2016 unterrichtet er agiles Projektmanagement an der deutschen Fakultät der TU Sofia.

Mehr interessante Artikel für dich:

Agiles vs. klassisches Projektmanagement | scagile Blog
Agiles Projektmanagement

Agiles vs. klassisches Projektmanagement

Häufig wird Teams der Unterschied zwischen agilem und klassischem Projektmanagement nicht richtig erklärt. Was ist der wesentliche Unterschied und wie vermeidet man, zurück in ein Micro-Management zu rutschen?

Lesen
Projektmanagement vs. Scrum | scagile Blog
Agiles Projektmanagement

Projektmanagement vs. Scrum

Inhalt Seitdem der Begriff ‚agiles Projektmanagement‘ aufgetaucht ist, gibt es eine fortwährende Diskussion über das Verhältnis von etablierten Projektmanagement Methoden (PMM) wie zum Beispiel PRINCE 2 oder PMI zu

Lesen