Cycle Time, Lead Time & Durchsatz – verständlich an einem Beispiel erklärt

Ein Board, ein Ticket – drei Perspektiven auf denselben Flow

In diesem Artikel betrachten wir die drei Basismetriken anhand eines Minimalbeispiels.

• Dein Team arbeitet mit einem Kanban-Board: Backlog → Selected → In Progress → Review → Done
• Am Montagmorgen landet ein neues Ticket im Backlog
• Am Mittwoch wird es für den nächsten Sprint ausgewählt (Selected)
• Am Donnerstag startet die eigentliche Arbeit (In Progress)
• Am darauffolgenden Dienstag wird das Ticket reviewed und gemerged (Review → Done)

Mit genau diesem einen Ticket können wir Cycle Time, Lead Time und Durchsatz sauber definieren – ohne die Beispiele ständig zu wechseln.

Lead Time – von „Wir brauchen das" bis „Es ist live"

Lead Time beantwortet die Frage: Wie lange dauert es von der ersten Anfrage bis zur Auslieferung?

In unserem Beispiel:

• Das Ticket taucht am Montag im Backlog auf (Anfrage erstellt)
• Es landet am darauffolgenden Dienstag in Done (Anfrage ausgeliefert)

Zählst du Kalendertage, sind das 8 Tage Lead Time. Lead Time ist meist die Metrik, auf die Business & Product schauen – sie beschreibt, wie lange jemand von „Bitte baut das" bis „Es ist da" warten muss.

Cycle Time – von „Wir arbeiten dran" bis „Wir sind fertig"

Cycle Time beantwortet: Wie lange ist das Ticket aktiv in Bearbeitung?

In unserem Beispiel:

• Das Ticket erreicht am Donnerstag die Commitment-Spalte (z. B. wenn es das Backlog verlässt und in In Progress gezogen wird)
• Es landet am darauffolgenden Dienstag in Done

Damit kommst du auf 5 Tage Cycle Time. Cycle Time ist der Teil der Lead Time, den dein Delivery-Team direkt beeinflusst – sie zeigt, wie flüssig der Flow ist, sobald ein Ticket tatsächlich gestartet wurde.

Cycle Time innerhalb der Lead Time visualisierenAbbildung 1: Oben die Lead Time von Backlog bis Done, unten die Cycle Time von der Commitment-Spalte bis zur Done-Spalte. Beide enden in Done, aber die Cycle Time startet später – dort, wo das Team die Arbeit wirklich übernimmt.

Abbildung 1 zeigt, wie die Commitment-Spalte den Startpunkt der Cycle Time markiert, während die Done-Spalte für beide Metriken das gemeinsame Ende bildet. Damit wird die Beziehung klar:

• Lead Time enthält alles von „Anfrage gestellt“ bis „ausgeliefert“ (Backlog → Done).
• Cycle Time fokussiert den zugesagten Arbeitsabschnitt von der Commitment-Spalte bis zur Done-Spalte.

Ist die Lead Time lang, die Cycle Time aber vergleichsweise kurz, liegen deine Engpässe meist davor (langes Warten im Backlog) oder dahinter (Review / QA / Deployment).

Durchsatz – wie viele Tickets wir in einem Zeitraum abschließen

Durchsatz beantwortet: Wie viele Tickets schließen wir pro Woche (oder Tag, Monat, …) ab?

In unserer Beispielwoche:

• Angenommen, zusätzlich zu unserem Beispielticket erreichen 6 weitere Tickets im selben Zeitraum Done
• Dann wären es insgesamt 7 Tickets, die in dieser Woche fertig werden

Dein Durchsatz für die Woche liegt also bei 7 Tickets/Woche. Durchsatz ist wie der Tacho deines Systems – er zeigt, wie viel Arbeit tatsächlich den Done-Status erreicht. Darauf baut jede realistische Prognose auf.

Durchsatz visualisierenAbbildung 2: Durchsatz-Chart, der die Anzahl der pro Tag abgeschlossenen Tickets zeigt. Jeder Balken repräsentiert Tickets, die an diesem Tag die Spalte "Done" erreicht haben.

Abbildung 2 macht sichtbar, wie häufig die Done-Spalte in einem Zeitraum erreicht wird und formt daraus ein messbares Durchsatzsignal. Konsistente Höhen deuten auf stabile Lieferung hin, während hohe Schwankungen auf Prozessinstabilität oder inkonsistente Arbeitsmuster hindeuten.

Die Metriken für das Beispiel zusammenfassen

Anhand dieses einfachen Beispiels können wir bereits sehen, wie die drei Metriken zusammenhängen:

• Lead Time (8 Tage) = Warten + aktive Arbeit + letzte Schritte bis Done
• Cycle Time (5 Tage) = nur die aktive Arbeit bis Done
• Durchsatz (7 Tickets/Woche) = wie viele Tickets im gleichen Zeitraum Done erreichen

Sie sind keine konkurrierenden Kennzahlen, sondern drei Blickwinkel auf denselben Flow:

• Lead Time spricht die Sprache der Kund:innen („Wie lange warte ich?“).
• Cycle Time spricht die Sprache des Delivery-Teams („Wie lange brauchen wir, wenn wir angefangen haben?“).
• Durchsatz spricht die Sprache des Systems („Wie viel liefern wir pro Zeiteinheit?“).

Was tun, wenn die Werte schwanken?

In der Realität sind diese Kurven nie perfekt glatt. Das ist normal – und die Schwankung ist genau das, was spannend ist. Typische Muster in Flussdiagrammen und was sie bedeuten können:

• Lead Time schwankt stark, Cycle Time ist relativ stabil: Der Engpass liegt häufig vor dem Start (Priorisierung, Warten auf Input) oder nach der Entwicklung (Review, Deployment).
• Cycle Time ist hoch variabel: „In Progress“ ist ein Mischmasch – Tickets sind sehr unterschiedlich groß, es gibt viel Kontextwechsel oder WIP-Limits werden ignoriert.
• Durchsatz springt stark von Woche zu Woche: Das System hat noch keinen stabilen Takt – es wird zu viel gestartet und zu wenig fertiggestellt.

Statt Ausreißer wegzudiskutieren, können diese als Ausgangspunkt für Gespräche im Team dienen:

• „Was war bei diesem Ticket anders?“
• „Warum ist der Durchsatz in diesem Sprint/Woche/Monat eingebrochen?“
• „In welcher Spalte hat dieses Ticket am längsten gelegen?“

Genau dort beginnt kontinuierliche Verbesserung.

In späteren Blogartikeln gehen wir noch tiefer darauf ein, wie kumulative Flussdiagramme (CFDs) und Monte-Carlo-Simulationen auf genau diesen drei Basismetriken aufbauen, um Prognosen und Kapazitätsgrenzen besser sichtbar zu machen.

Wie flowban bei diesen drei Metriken hilft

flowban verbindet sich direkt mit deinen GitHub Projects und berechnet die drei Basismetriken für dich:

• Lead Time: von der ersten Sichtbarkeit eines Issues auf deinem Board bis zur Done-Spalte.
• Cycle Time: von der Verpflichtung (z. B. wenn ein Item das Backlog verlässt oder In Progress betritt) bis Done.
• Durchsatz: wie viele Issues pro Tag, Woche oder Monat Done werden.

Mit flowban erhältst du Zugang zu Diagrammen wie den oben gezeigten, angepasst an deinen Workflow und deine Board-Konfiguration – damit du:

• Engpässe früh erkennst, weil sichtbar wird, wo sich Arbeit auf dem Board staut.
• Lieferfähigkeit stabilisierst, indem Lead Time, Cycle Time und Durchsatz über die Zeit vergleichbar und messbar werden.
• Lieferverhalten mit Daten erklärst – statt Diskussionen auf Bauchgefühl zu führen.
• Die Basis für weiterführende Analysen schaffst, z. B. für CFDs und Monte-Carlo-Simulationen, ohne eigene Skripte oder Excel-Bastellösungen.

Alle drei Metriken bleiben an dieselbe Realität gekoppelt: Issues, die sich über dein GitHub-Board bewegen.