Was ist Cycle Time?

Die Cycle Time (dt. Zykluszeit, manchmal auch als Durchlaufzeit bezeichnet) misst die Zeitspanne, die zwischen dem Beginn einer Arbeit und dem Abschluss einer Arbeit vergeht. Sie ist neben Work In Progress, Throughput und Work Item Age eine von vier zentralen Kanban-Metriken und unterstützt Dein Team dabei, seinen Workflow zu verbessern.

Weil die Cycle Time erst im Nachhinein (also nach Abschluss eines Work Items) ermittelt werden kann, gehört sie zu den sogenannten Lagging Indicators.

Verwirrenderweise wird die Cycle Time im Deutschen manchmal als Zykluszeit und manchmal als Durchlaufzeit bezeichnet. (Im deutschsprachigen Kanban Guide für Scrum Teams steht beispielsweise die Cycle Time wäre die Durchlaufzeit.)

Wörtlich aus dem Englischen übersetzt, ist sie natürlich die Zykluszeit. Die Durchlaufzeit hingegen ist die sogenannte Lead Time. Das Ganze wird klarer, wenn Du Dir bewusst machst, auf welche Bereiche Eures Workflows sich beide Metriken beziehen.

Einfach gesprochen umspannt die Cycle Time lediglich die Arbeitsstatus in der Kategorie Doing, während die Lead Time die Status in To Do & Doing umfasst.

Manchmal kann es neben Lead und Cycle Time sogar noch sinnvoll sein, die Customer Cycle Time zu messen. Und zwar immer dann, wenn der Workflow eines Teams zwar endet, aber das Ergebnis noch gar nicht beim Kunden verfügbar ist. Etwa weil es feste Release-Zyklen gibt, in denen Software an Kunden ausgespielt wird.

Hier rechts habe ich Dir einmal alle drei Metriken anhand des Workflows eines Scrum Teams visualisiert. Die Lead Time umfasst wie Du siehst auch die Zeit, in der Work Items noch im Product Backlog “schlummern” und an denen noch gar nicht aktiv gearbeitet wird.

Die Cycle Time Eures Workflows basiert auf der Definition of Workflow (DoW) Eures Teams. Denn in der DoW legt Ihr unter anderem fest, wann Arbeit als begonnen und wann sie als beendet gilt.

Je nachdem, wie Eure Definition of Workflow also ausfällt, hat das direkte Auswirkungen darauf, was Ihr mit Hilfe Eurer Zykluszeit messen werdet.

Bei der Definition Eures Workflows solltet Ihr Euch daher immer auch fragen, wie aussagekräftig die daraus resultierende Cycle Time später sein wird und was sie bedeutet.

Wichtig ist außerdem, dass die Cycle Time etwas anderes ist als die Zeit, in der aktiv an einem Work Item gearbeitet wird. Sie läuft sozusagen immer weiter, sobald ein Work Item begonnen wurde. (Auch wenn zwischendurch nicht daran gearbeitet wird.)

Wenn zum Beispiel heute für 2 Stunden an einem Work Item gearbeitet wird, es dann liegenbleibt und in der nächsten Woche mit einem Aufwand von weiteren 2 Stunden abgeschlossen wird, beträgt die Cycle Time 1 Woche und nicht 4 Stunden.

Die Verbesserung und Optimierung Eures Workflows hat stets zum Ziel, die Zykluszeit Eures Workflows verringert. Allerdings habt Ihr keinen direkten Einfluss auf Eure Cycle Time. Es bringt ja wenig bis nichts, Euch gegenseitig anzufeuern oder Euch darauf zu einigen, schneller zu arbeiten.

An dieser Stelle kommt eine mathematische Formel ins Spiel, die auch als Little’s Law bekannt geworden ist. Nach dieser Formel ist die durchschnittliche Cycle Time eines Teams (oder Systems) gleich dem durchschnittlichen Work In Progress geteilt durch den durchschnittlichen Throughput dieses Teams (oder Systems).

Auf zwei der drei Metriken aus Little’s Law hat Euer Team keinen direkten Einfluss.

Weder können Ihr Eure Zykluszeit verringern, indem Ihr Euch darauf einigt “schneller zu arbeiten”, noch könnt Ihr einfach beschließen, “in der gleichen Zeit mehr fertigzustellen”. Was einer Erhöhung des Throughputs gleichkäme und im Grunde dasselbe wäre.

Allerdings habt Ihr Einfluss auf die dritte Metrik aus Little’s Law: Work In Progress. Denn Ihr könnt die Menge an Arbeit begrenzen, die parallel bzw. gleichzeitig von Euch erledigt wird.

Laut Little’s Law verringert sich jedoch die durchschnittliche Cycle Time, wenn der Work In Progress (WIP) verringert wird.

In der Praxis kannst Du die Cycle Time mit Hilfe von zwei verschiedenen Kanban Charts visualisieren. Zum einen mit Hilfe des Cumulative Flow Diagrams (CFD) und zum anderen mit dem Cycle Time Scatterplot.

Hierbei musst Du jedoch ein wenig aufpassen, denn beide Charts visualisieren unterschiedliche Durchschnittswerte für die Cycle Time! Das CFD visualisiert die ungefähre durchschnittliche Cycle Time. Das Cycle Time Scatterplot hingegen visualisiert die exakte durchschnittliche Cycle Time.

Auf dem Cumulative Flow Diagram (CFD) kannst Du die ungefähre durchschnittliche Cycle Time Eures Teams als horizontale Linie ermitteln, die sich vom ersten bis zum letzten aktiven Arbeitsstatus Eures Workflows spannt.

Darüber hinaus kannst Du über ein CFD auch den durchschnittlichen Work In Progress und Throughput Eures Teams ablesen.

Deutlich informativer ist hingegen das sogenannte Cycle Time Scatterplot (CTS). Im Gegensatz zum CFD kannst Du mit diesem Kanban Chart nämlich die exakte durchschnittliche Cycle Time für alle (abgeschlossenen) Work Item ermitteln.

Außerdem kannst Du mit diesem Kanban Chart einen Forecast für Dein Team ermitteln und eine Service Level Expectation abgeben.