Cycle Time

Die Cycle Time misst, wie viele Kalendertage vergehen, von dem Moment an, in dem die Arbeit an einer Aufgabe beginnt, bis sie dem Kunden zur Verfügung steht. Sie startet am Commitment Point, nicht beim Eingang der Anforderung.

Geprüft am 2026-08-16 · Thomas Esders · CC BY-SA 4.0

Durch die Work–Feedback Loop betrachtet

Cycle Time misst, wie schnell dein System produziert. Nicht, wie schnell es lernt. In der Work–Feedback Loop heißt diese Größe Produktionsgeschwindigkeit, und sie ist nur die eine Hälfte des Kreislaufs.

Du kannst deine Cycle Time halbieren und trotzdem träge bleiben. Nämlich dann, wenn die Rückmeldung zur ausgelieferten Arbeit erst Wochen später ankommt. Schnell liefern und schnell lernen sind zwei verschiedene Dinge.

Eine kurze Cycle Time ist deshalb kein Selbstzweck. Ihr Wert liegt darin, dass sie den Abstand zwischen Handlung und Wirkung verkürzt und dir überhaupt erst die Gelegenheit verschafft, etwas zu erfahren. Wer nur die Auslieferung beschleunigt und den Rückweg lässt, wie er ist, produziert schneller an der Realität vorbei.

Häufiges Missverständnis

Cycle Time und Lead Time werden ständig verwechselt. Der Unterschied ist keine Feinheit. Er entscheidet darüber, was du überhaupt misst.

Die Lead Time beginnt, wenn der Kunde die Anforderung stellt. Die Cycle Time erst, wenn ihr sie tatsächlich anfasst. Was dazwischen liegt, ist Wartezeit. Und die ist in den meisten Systemen der größere Anteil.

Wer nur die Cycle Time optimiert, lässt die Wartezeit davor unbemerkt wachsen und hält sich trotzdem für schneller. Aus Kundensicht hat sich nichts verbessert. Die Anforderung liegt genauso lange herum wie vorher, nur an einer anderen Stelle.

Was das in der Praxis heißt

Cycle Time steht in einem festen Verhältnis zu angefangener Arbeit und Durchsatz. Das ist keine Empfehlung. Das ist Mathematik. Wenn du die Menge paralleler Arbeit senkst, sinkt die Cycle Time, ohne dass irgendjemand schneller arbeitet.

Umgekehrt gilt dasselbe, und das ist der unangenehme Teil. Jede zusätzlich angefangene Aufgabe verlängert die Wartezeit für alles, was schon im System steckt, weil sich alle Karten dieselbe Kapazität teilen und jede zusätzliche die Warteschlange für die anderen verlängert. Eine wachsende Cycle Time zeigt deshalb selten langsame Arbeit an. Sie zeigt zu viel gleichzeitig Angefangenes.

Ein Beispiel. Ihr habt im Schnitt 10 Aufgaben gleichzeitig offen und schafft 2 pro Woche. Dann liegt eure Cycle Time bei 5 Wochen. Senkt ihr die offenen Aufgaben auf 4, sind es 2 Wochen. Niemand hat schneller gearbeitet.

Als erste Zahl für euren Fluss ist die Cycle Time die naheliegendste. Sie braucht keine Schätzung, keine Story Points, keine Einigung über Aufwand. Zwei Zeitstempel reichen.

Mehr ist es nicht.

Verwandte Begriffe

• Wirkt aufWiP-Limit – senkt die angefangene Arbeit und damit die Cycle Time
• Wirkt aufLittle's Law – beschreibt den Zusammenhang rechnerisch
• GegenstückLead Time – misst zusätzlich die Wartezeit vor dem Arbeitsbeginn
• Siehe auchNo Estimates – der Ansatz, der auf Messung statt Schätzung setzt
• OberbegriffFlow-Messung – die Kennzahlen, zu denen sie gehört