Was ist Cycle Time?

Die Cycle Time (dt. Durchlaufzeit) 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 sie erst im Nachhinein (also nach Abschluss eines Work Items) ermittelt werden kann, gehört sie zu den sogenannten Lagging Indicators.

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 Durchlaufzeit 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.)

Die Verbesserung und Optimierung Eures Workflows hat stets zum Ziel, die Durchlaufzeit 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 Durchlaufzeit 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 und zum anderen mit dem Cycle Time Scatterplot.

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

Außerdem 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 Cycle Time für jedes (abgeschlossene) Work Item ermitteln.

Darüber hinaus kannst Du mit diesem Kanban Chart einen Forecast für Dein Team ermitteln und eine Service Level Expectation abgeben.

Neben der Cycle Time existieren noch viele weitere Metriken, die in Kanban genutzt werden können.

Beispielsweise die Lead Time oder auch die Customer Cycle Time. Im Vergleich zur Durchlaufzeit beginnt die Lead Time bereits dann, wenn Eurem Team bekannt ist, dass eine Aufgabe (irgendwann) erledigt werden muss bzw. soll.

Die Customer Cycle Time hingegen ist dann sinnvoll, wenn ein Work Item nach Abschluss Eurer Arbeit nicht direkt für den Kunden oder Nutzer verfügbar ist. Das geschieht beispielsweise dann, wenn Updates in festen Release-Zyklen an Kunden ausgeliefert werden.