Cycle Time, Throughput und Work-in-Progress sind keine unabhängigen Kennzahlen, aus denen man sich die passende aussucht.
Sie bilden ein System, verbunden durch einen mathematischen Zusammenhang, und wer diesen versteht, erkennt schnell, wo der wirksamste Hebel liegt. Die ersten beiden Teile dieser Serie haben geklärt, für wen und wozu gemessen werden soll und was Lieferfähigkeit als Konzept umfasst. Die drei Dimensionen stehen: Geschwindigkeit, Durchsatz und Vorhersagbarkeit. Jetzt geht es um die konkreten Metriken, die diese Dimensionen abbilden.
Cycle Time misst die Zeitspanne vom Beginn der aktiven Arbeit an einer Aufgabe bis zu deren Fertigstellung. Nicht die Zeit vom Wunsch bis zur Lieferung, nicht die Zeit im Backlog, nicht die Wartezeit vor dem Start. Sobald jemand beginnt, an einem Feature, einem Bugfix oder einer Aufgabe zu arbeiten, startet die Uhr. Wenn das Ergebnis ausgeliefert ist, stoppt sie.
Diese Abgrenzung ist wichtig, weil Cycle Time häufig mit Lead Time verwechselt wird. Lead Time umfasst die gesamte Zeitspanne aus Sicht der Anfordernden, also von dem Moment, in dem ein Wunsch oder eine Anforderung formuliert wird, bis zur Auslieferung. Sie schließt die Wartezeit im Backlog mit ein und ist damit die relevantere Metrik für Stakeholder, die wissen wollen, wie lange sie auf ein Ergebnis warten. Für die Prozesssteuerung innerhalb des Entwicklungssystems ist Cycle Time jedoch aussagekräftiger, weil sie zeigt, was passiert, sobald Arbeit tatsächlich begonnen wurde.
Was Cycle Time sichtbar macht, sind die Phasen, die eine Aufgabe durchläuft, und vor allem die Wartezeiten zwischen diesen Phasen. Eine Aufgabe verbringt den Großteil ihrer Durchlaufzeit typischerweise nicht in aktiver Bearbeitung, sondern beim Warten. Cycle Time macht dieses Warten messbar und damit adressierbar. Wer die Cycle Time einer Aufgabe in ihre Bestandteile zerlegt, also in Bearbeitungszeit und Wartezeit pro Phase, stößt häufig auf überraschende Verteilungen. Das Code-Review zum Beispiel, das zwei Stunden aktive Arbeit erfordert, wartet drei Tage auf einen Reviewer. Oder die Testphase dauert einen halben Tag, aber die Aufgabe lag vorher vier Tage in der Queue. Diese Transparenz ist der erste Schritt zu gezielter Verbesserung, weil sie zeigt, wo Optimierung tatsächlich Wirkung entfalten kann und wo sie verpufft.
Ein häufiges Missverständnis ist die Verwendung von Cycle Time als Leistungsmetrik für einzelne Personen. Wenn ein Feature vier Wochen Cycle Time hat, liegt das in den seltensten Fällen daran, dass jemand vier Wochen lang daran gearbeitet hat. Es liegt daran, dass das Feature vier Wochen im System war, davon vielleicht fünf Tage in aktiver Bearbeitung und den Rest in Warteschlangen. Cycle Time ist eine Prozessmetrik, keine Personalmetrik. Wer sie als Letzteres nutzt, erzeugt Fehlanreize.
Throughput misst die Anzahl abgeschlossener Arbeitseinheiten pro Zeitraum. Zehn fertiggestellte Features pro Monat, fünf abgeschlossene Aufgaben pro Woche oder drei ausgelieferte Bugfixes pro Tag sind dafür Beispiele. Die Einheit und der Zeitraum variieren je nach Kontext, aber das Prinzip bleibt gleich: Throughput zählt, was am Ende des Systems herauskommt, nicht was hineingeht oder sich darin befindet.
Eine oft unterschätzte Frage bei der Messung von Throughput ist die Definition der Arbeitseinheit. Zählt man Features, User Stories, Tickets, oder etwas anderes? Die Antwort hat direkte Konsequenzen für die Aussagekraft. Wer Tickets zählt, zählt möglicherweise eine Mischung aus großen Features und kleinen Bugfixes, was die Vergleichbarkeit über Zeiträume hinweg erschwert. Eine pragmatische Lösung liegt darin, auf eine halbwegs einheitliche Granularität zu achten, also Aufgaben so zu schneiden, dass sie in ihrer Größenordnung vergleichbar sind. Perfektion ist dabei weder nötig noch erreichbar, aber eine grobe Konsistenz macht Throughput-Daten erst interpretierbar.
In der Praxis wird Throughput oft zugunsten von Geschwindigkeit übersehen. Organisationen investieren viel Energie in die Frage, wie lange einzelne Aufgaben dauern, und deutlich weniger in die Frage, wie viel insgesamt fertig wird. Dabei ist Throughput für Kapazitätsplanung und Forecasting die entscheidendere Größe. Wer wissen will, ob ein bestimmter Umfang an Arbeit bis zu einem Termin abgeschlossen sein kann, braucht als Eingangsgröße den historischen Throughput, nicht die Cycle Time einzelner Aufgaben. Monte-Carlo-Simulationen, wie sie im Forecasting-Artikel beschrieben werden, basieren im Kern auf genau dieser Größe.
Was Throughput nicht verrät, ist der erzeugte Wert. Zwanzig abgeschlossene Aufgaben pro Woche können beeindruckend oder bedeutungslos sein, je nachdem, ob es sich um wertschöpfende Features oder um Nacharbeiten handelt, die durch mangelnde Qualität entstanden sind. Die Unterscheidung zwischen Output und Outcome bleibt bei der Interpretation unverzichtbar.
Work-in-Progress, kurz WIP, bezeichnet die Anzahl gleichzeitig begonnener, aber noch nicht abgeschlossener Aufgaben. Anders als Cycle Time und Throughput ist WIP keine reine Beobachtungsgröße. WIP ist eine Steuerungsgröße, und das macht den entscheidenden Unterschied.
Ein wesentliches Problem in der Softwareentwicklung ist, dass WIP unsichtbar ist. In einer Fabrik sieht man die halbfertigen Produkte, die sich zwischen den Stationen stapeln. In der Softwareentwicklung verteilt sich die angefangene Arbeit auf Tickets in (verschiedenen?) Boards, auf Branches in Repositories, auf offene Pull-Requests und auf Entwürfe in den Köpfen der Beteiligten. Niemand stolpert im Büroflur über einen Stapel unfertiger Features. Deshalb unterschätzen die meisten Teams ihren tatsächlichen WIP erheblich. Ein ehrlicher Blick auf die Anzahl der Aufgaben, die begonnen, aber nicht abgeschlossen sind, produziert regelmäßig Überraschung.
Cycle Time und Throughput kann man messen und analysieren, aber nicht direkt verändern. Man kann niemandem anordnen, schneller zu arbeiten, und man kann nicht per Dekret mehr Durchsatz erzeugen. WIP hingegen lässt sich direkt beeinflussen, indem die Menge gleichzeitig laufender Arbeit bewusst begrenzt wird. Das kann über explizite Obergrenzen für die Anzahl paralleler Aufgaben geschehen oder über das Prinzip, neue Arbeit erst dann zu beginnen, wenn bestehende Arbeit abgeschlossen ist. Die konkreten Mechanismen dafür sind ein eigenes Thema, aber das Grundprinzip lässt sich in einem Satz zusammenfassen: weniger anfangen, mehr fertigstellen.
Warum WIP so zentral ist, wird durch einen Blick auf die Konsequenzen hoher WIP-Werte deutlich. Jede zusätzliche parallele Aufgabe erzeugt Kontextwechsel, die kognitive Kosten verursachen. Jede angefangene, aber nicht fertige Aufgabe belegt Kapazität, ohne Wert zu liefern. Und je mehr Aufgaben gleichzeitig im System sind, desto länger warten sie in Warteschlangen auf den nächsten Bearbeitungsschritt. Dabei zählen nicht nur die offiziell begonnenen Tickets, sondern auch die „nebenbei“ laufenden Aufgaben, die auf keinem Board stehen, aber trotzdem mentale Kapazität binden. Die Analyse der Kosten von Aufgabenwechseln zeigt, wie schnell sich diese Kosten summieren. Und der Auslastungs-Artikel erklärt die Warteschlangentheorie dahinter: Ab einer bestimmten Auslastung steigen Wartezeiten nicht linear, sondern exponentiell.
WIP ist also nicht einfach eine weitere Metrik neben Cycle Time und Throughput. WIP ist der Eingang, die anderen beiden sind Ergebnisse. Und der Zusammenhang zwischen den dreien ist kein Zufall, sondern ein mathematisches Gesetz.
1961 formulierte der Mathematiker John D. C. Little einen Zusammenhang, der seitdem in Bereichen von der Telekommunikation bis zur Fertigung Anwendung findet: Die durchschnittliche Anzahl von Einheiten in einem System entspricht dem Produkt aus dem durchschnittlichen Durchsatz und der durchschnittlichen Verweildauer. In der Notation, die für Softwareentwicklung gebräuchlich ist, lautet die Formel:
Cycle Time = WIP / Throughput
Der Kern ist simpel: Wer WIP senkt, ohne dass der Throughput einbricht, verkürzt die Cycle Time. Wer WIP erhöht, ohne den Throughput proportional zu steigern, verlängert sie. Das ist keine Theorie, sondern eine mathematische Notwendigkeit, solange das System bestimmte Stabilitätsbedingungen erfüllt.
Die praktische Implikation für Entwicklungsorganisationen ist erheblich. Wenn ein Team aktuell fünfzehn Aufgaben gleichzeitig in Bearbeitung hat und einen Throughput von fünf Aufgaben pro Woche, dann beträgt die durchschnittliche Cycle Time drei Wochen. Reduziert das Team seinen WIP auf zehn, bei stabilem Throughput, sinkt die Cycle Time auf zwei Wochen. Ohne dass irgendjemand schneller arbeitet. Ohne zusätzliche Kapazität. Ohne neue Tools oder Prozesse. Allein durch weniger Gleichzeitigkeit.
Das klingt zu einfach, um wahr zu sein, und genau deshalb stößt die Konsequenz in der Praxis auf Widerstand. Weniger WIP bedeutet, dass bestimmte Aufgaben bewusst nicht sofort begonnen werden. In Organisationen, die hohe Auslastung mit Produktivität gleichsetzen, fühlt sich das nach Verschwendung an. Die Vorstellung, dass jemand „nichts zu tun hat“, weil das WIP-Limit erreicht ist, widerspricht tief verankerten Überzeugungen darüber, wie produktive Arbeit aussieht. Dabei zeigt Little’s Law genau das Gegenteil: Die vermeintliche Untätigkeit erzeugt kürzere Lieferzeiten, weil die Warteschlangen im System schrumpfen. Die frei werdende Kapazität fließt idealerweise in die Fertigstellung angefangener Arbeit, in Qualitätsverbesserung oder in die Beseitigung von Hindernissen, die den Fluss bremsen. Reinertsen beschreibt in „The Principles of Product Development Flow“, warum die Blindheit gegenüber Warteschlangen zu den hartnäckigsten Problemen in Entwicklungsorganisationen gehört und warum gerade die Überzeugung, Kapazität müsse voll ausgelastet sein, die Bildung dieser Warteschlangen antreibt.
Eine wichtige Einschränkung: Little’s Law gilt für stabile Systeme. Das bedeutet, dass sich WIP, Throughput und Cycle Time über den betrachteten Zeitraum nicht drastisch verändern und dass alles, was ins System eingeht, es auch irgendwann wieder verlässt. In der Realität sind Softwareentwicklungssysteme selten perfekt stabil. Prioritäten wechseln, ungeplante Arbeit kommt herein, Aufgaben werden abgebrochen. Je instabiler das System, desto ungenauer die Vorhersagen auf Basis von Little’s Law. Das bedeutet nicht, dass das Gesetz in der Praxis nutzlos ist. Es bedeutet, dass die erste Aufgabe darin besteht, das System stabiler zu machen, also Variabilität zu reduzieren, bevor man die Formel für belastbare Prognosen nutzt. Die Begrenzung von WIP ist, neben der Stabilisierung des Zuflusses, einer der wirksamsten Hebel dafür.
Cycle Time, Throughput und WIP entfalten ihren Nutzen erst, wenn sie gemeinsam betrachtet werden. Einzeln genommen können sie in die Irre führen. Zusammen gelesen ergeben sie ein Bild, das systemische Probleme sichtbar macht.
Drei Muster tauchen in der Praxis besonders häufig auf.
Das verbreitetste Muster: WIP steigt, Cycle Time steigt mit, Throughput stagniert oder sinkt. Das ist das klassische Zeichen dafür, dass zu viel gleichzeitig begonnen wird. Mehr Arbeit im System führt nicht zu mehr Ergebnissen, sondern zu längeren Wartezeiten. Die Ursachen sind vielfältig, von fehlendem Nein-Sagen gegenüber neuen Anforderungen über mangelnde Priorisierung bis zu organisatorischen Strukturen, die parallele Arbeit erzwingen, etwa wenn ein Team mehrere Produktlinien gleichzeitig betreut. Die Lösung liegt nicht darin, schneller zu arbeiten, sondern darin, weniger gleichzeitig zu tun.
Das zweite Muster: Cycle Time bleibt stabil, aber Throughput sinkt. Hier liegt kein WIP-Problem vor, sondern ein Kapazitäts- oder Komplexitätsproblem. Möglicherweise ist das Team geschrumpft, die Aufgaben sind komplexer geworden, oder externe Abhängigkeiten bremsen die Fertigstellung. Auch ein schleichender Anstieg von Wartungsarbeit oder technischen Schulden kann dieses Muster erklären, weil dann zwar jede einzelne Aufgabe in ähnlicher Zeit abgeschlossen wird, aber weniger Aufgaben insgesamt bearbeitet werden können. Die Antwort auf dieses Muster ist eine andere als beim ersten, und genau deshalb ist die Kombination der Metriken so aufschlussreich.
Das dritte Muster: Cycle Time sinkt, WIP sinkt, Throughput bleibt gleich oder steigt leicht. Das ist das Muster, das zeigt, dass WIP-Begrenzung wirkt. Weniger parallele Arbeit führt zu kürzeren Durchlaufzeiten, ohne den Output zu reduzieren. Für Stakeholder, die befürchten, dass WIP-Limits die Leistung bremsen, ist dieses Muster der überzeugendste Gegenbeweis. Es zeigt in den eigenen Daten, was die Theorie vorhersagt.
Die Frage ist, welche Kombination für welche Zielgruppe relevant ist. Die Geschäftsführung interessiert sich primär für Throughput-Trends auf Quartalsebene und für die daraus ableitbare Vorhersagbarkeit. Engineering-Verantwortliche schauen auf das Zusammenspiel aller drei Metriken, um systemische Engpässe zu identifizieren. Und für das Team selbst ist WIP die Metrik mit der unmittelbarsten Handlungsrelevanz, weil sie direkt beeinflusst werden kann.
Cycle Time und Throughput sind Ergebnisgrößen. Sie zeigen, was das System produziert. WIP ist die Eingangsgröße, über die sich das System steuern lässt. Little’s Law verbindet die drei zu einem Zusammenhang, der erklärt, warum weniger Gleichzeitigkeit zu besseren Ergebnissen führt.
Wer die Lieferfähigkeit verbessern will, tut gut daran, zuerst auf WIP zu schauen, bevor andere Hebel in Betracht gezogen werden. Geschwindigkeit und Durchsatz verbessern sich häufig als Konsequenz.
Was in diesem Modell noch fehlt, ist die dritte Dimension: Vorhersagbarkeit. Durchschnittswerte, wie Little’s Law sie liefert, sind ein Anfang. Aber für verlässliche Prognosen reichen sie nicht, weil sie die Streuung verdecken. Wie sich Vorhersagbarkeit konkret messen lässt, ist ein eigenständiges Thema, welches einen eigenen Artikel bekommt.
Buchen Sie jetzt Ihre kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.