Ein Team liefert Features im Durchschnitt in zehn Tagen. Klingt solide, klingt planbar. Bis man die einzelnen Datenpunkte betrachtet und feststellt, dass die tatsächlichen Lieferzeiten zwischen drei und dreißig Tagen schwanken.
Mit dieser Bandbreite lässt sich keine seriöse Zusage machen. Und genau hier liegt das Problem: Durchschnittswerte, wie sie über Little’s Law eingeführt wurden, beschreiben das System im Mittel. Sie verraten aber nichts darüber, wie verlässlich dieses Mittel ist.
Neben Geschwindigkeit und Durchsatz ist Vorhersagbarkeit eine eigenständige Dimension von Lieferfähigkeit. Für Entscheidungsträger ist sie häufig die wertvollste der drei, weil sie die Grundlage für strategische Planung bildet. Roadmap-Commitments, Kundenzusagen und Investitionsentscheidungen setzen voraus, dass die Organisation einschätzen kann, was sie bis wann liefern wird. Der Durchschnitt ist der Startpunkt, nicht das Ziel. Was für Prognosen und Zusagen tatsächlich gebraucht wird, ist ein Verständnis der Streuung.
Zwei Teams haben eine durchschnittliche Cycle Time von zwölf Tagen. Team A liefert konstant zwischen zehn und vierzehn Tagen. Team B schwankt zwischen zwei und vierzig Tagen. Der Mittelwert ist identisch, die Planbarkeit ist es nicht. Bei Team A lässt sich mit hoher Sicherheit sagen, dass ein Feature in rund zwei Wochen fertig sein wird. Bei Team B ist dieselbe Aussage nicht mehr als ein Münzwurf.
Der Durchschnitt verdeckt diesen Unterschied vollständig. Schlimmer noch: Er erzeugt eine trügerische Präzision.
Wer einem Stakeholder sagt: „Unsere durchschnittliche Durchlaufzeit beträgt zwölf Tage“, weckt die Erwartung, dass das nächste Feature in etwa zwölf Tagen fertig sein wird. Wenn es dann dreißig Tage dauert, entsteht nicht der Eindruck einer statistischen Schwankung, sondern der Eindruck gebrochener Zusagen. Das Vertrauen leidet, obwohl der Durchschnitt technisch korrekt war.
Das Problem verschärft sich dadurch, dass Cycle-Time-Verteilungen in der Softwareentwicklung typischerweise nicht symmetrisch sind. Sie sind rechtsschief: Viele Aufgaben werden relativ schnell fertig, aber einige wenige dauern deutlich länger als der Rest. In solchen Verteilungen liegt der Durchschnitt höher als der Median, und ein einzelner Ausreißer nach oben kann den Mittelwert drastisch verschieben. Wer den Durchschnitt als Planungsgröße nutzt, plant also systematisch mit einem Wert, der von den Extremfällen verzerrt wird, statt das typische Verhalten des Systems abzubilden.
Führungskräfte fragen trotzdem reflexartig nach Durchschnittswerten, weil sie eine einzelne, handliche Zahl erwarten. Die Antwort „Es kommt darauf an“ gilt als Ausweichen. Doch genau diese Antwort ist häufig die ehrlichere. Die bessere Alternative zum Durchschnitt ist nicht Vagheit, sondern eine differenziertere Form der Aussage, die die Streuung berücksichtigt, statt sie zu verschleiern.
Perzentilwerte lösen das Problem, indem sie Wahrscheinlichkeiten mit konkreten Zeitangaben verbinden. Das 85. Perzentil der Cycle Time sagt: 85 Prozent aller Aufgaben wurden innerhalb dieses Zeitrahmens abgeschlossen. Daniel Vacanti beschreibt in „Actionable Agile Metrics for Predictability“ ausführlich, warum Perzentilwerte für die Praxis tauglicher sind als Durchschnitte und wie sie sich aus historischen Cycle-Time-Daten ableiten lassen.
Die Wahl des Perzentils ist eine bewusste Abwägung zwischen Risiko und Konservatismus. Das 50. Perzentil bedeutet: Jede zweite Aufgabe dauert länger als dieser Wert. Als Grundlage für Zusagen ist das zu riskant, weil die Hälfte aller Commitments gerissen wird. Das 95. Perzentil ist so konservativ, dass die resultierende Zeitangabe für Stakeholder inakzeptabel großzügig wirkt und die Organisation sich unnötig Spielraum nimmt, den sie nicht braucht. Das 85. Perzentil hat sich als pragmatischer Richtwert etabliert, weil es ein gutes Gleichgewicht bietet: Es ist konservativ genug, um die meisten Schwankungen abzufangen, aber nicht so konservativ, dass die Zusagen unrealistisch aufgeblasen wirken.
Welches Perzentil die richtige Wahl ist, hängt allerdings auch vom Kontext ab. Für eine Zusage gegenüber einem externen Kunden, bei der ein Vertragsrisiko besteht, kann das 95. Perzentil angemessener sein. Für eine interne Planung, bei der Anpassungen möglich sind, reicht möglicherweise das 70. Perzentil. Die Entscheidung ist keine rein statistische, sondern eine über die Risikobereitschaft der Organisation. Entscheidend ist, dass die Entscheidung bewusst getroffen wird und nicht implizit durch die Verwendung eines Durchschnitts, der das Risiko verschleiert.
Der praktische Nutzen zeigt sich in der Art, wie Zusagen formuliert werden können. Statt „Das Feature dauert zwölf Tage“ lässt sich sagen: „85 Prozent unserer Features werden innerhalb von fünfzehn Tagen oder früher fertig. In seltenen Fällen kann es bis zu drei Wochen dauern.“
Diese Aussage ist ehrlicher, vertretbarer und für Stakeholder paradoxerweise oft befriedigender als eine Punktschätzung, die nachher nicht eintrifft. Sie zeigt, dass die Organisation ihre eigene Leistungsfähigkeit versteht und mit der Unsicherheit ehrlich umgeht, statt sie hinter einem Durchschnitt zu verstecken.
Ein weiterer Vorteil gegenüber Einzelschätzungen: Perzentilwerte basieren auf dem tatsächlichen Verhalten des Systems, nicht auf der Einschätzung einzelner Personen. Sie sind damit resistent gegen die kognitiven Verzerrungen, die bei klassischen Schätzungen regelmäßig zuschlagen und die im Artikel über systematische Fehlschätzungen beschrieben werden. Die Daten erzählen, was das System tatsächlich leistet, nicht was jemand glaubt, dass es leisten müsste.
Streuung ist nicht nur ein Problem für Prognosen. Sie ist ein Signal, das auf systemische Instabilität hinweist. Wenn die Cycle Times eines Teams stark schwanken, dann nicht, weil manche Aufgaben eben länger dauern als andere. Zumindest ist das selten die ganze Erklärung. Hohe Streuung deutet auf unkontrollierte Variabilität im System hin, und die Quellen dieser Variabilität sind meist organisatorischer, nicht technischer Natur: Aufgaben mit stark unterschiedlicher Granularität, die in denselben Workflow fließen, weil niemand sie vorher auf eine handhabbare Größe bringt. Unvorhersehbare Blockaden durch externe Abhängigkeiten, die außerhalb des Einflussbereichs des Teams liegen. Ständig wechselnde Prioritäten, die angefangene Arbeit unterbrechen und damit die Verweildauer im System verlängern. Versteckte Nacharbeiten, die manche Aufgaben unerwartet verlängern, weil Qualitätsprobleme erst spät im Prozess sichtbar werden.
Jede dieser Quellen erzeugt ein eigenes Muster in den Daten. Abhängigkeiten zeigen sich als plötzliche Plateaus in der Cycle Time, bei denen eine Aufgabe tagelang in einem bestimmten Status verharrt. Wechselnde Prioritäten erzeugen eine bimodale Verteilung, in der schnell durchgezogene Aufgaben neben lange liegengebliebenen koexistieren. Inkonsistente Aufgabengrößen zeigen sich als gleichmäßig breite Streuung über das gesamte Spektrum.
Wer die Streuung reduziert, verbessert dadurch nicht nur die Vorhersagbarkeit, sondern adressiert in der Regel gleichzeitig die Ursachen für lange Durchlaufzeiten. Das liegt daran, dass die Hebel zur Reduktion von Variabilität weitgehend dieselben sind, die auch Geschwindigkeit und Durchsatz verbessern: konsistentere Aufgabengrößen, weniger parallele Arbeit, stabilerer Zulauf, klarere Abhängigkeiten. Die Begrenzung von WIP, wie im vorherigen Teil beschrieben, ist einer der wirksamsten Hebel dafür, weil sie die Menge an Variabilität reduziert, die das System verarbeiten muss.
Ein praktischer Ansatzpunkt ist die Analyse der Ausreißer. Wenn die meisten Aufgaben in acht bis fünfzehn Tagen abgeschlossen werden, aber regelmäßig einzelne Aufgaben dreißig oder mehr Tage benötigen, lohnt es sich, gezielt diese Ausreißer zu untersuchen. Was haben sie gemeinsam? Häufig zeigen sich Muster: Aufgaben mit externen Abhängigkeiten, Aufgaben, die auf bestimmte Spezialisten warten müssen, oder Aufgaben, die während der Bearbeitung mehrfach umpriorisiert wurden. Diese Muster zu erkennen, ist wertvoller, als jeden einzelnen Ausreißer zu erklären, weil sie auf systemische Ursachen hinweisen, die sich adressieren lassen.
Streuung zu beobachten erfordert keine komplexen statistischen Werkzeuge. Schon ein Blick auf die Verteilung der Cycle Times über einige Wochen hinweg zeigt, ob das System stabil oder volatil arbeitet. Diagrammtypen wie Scatterplots oder Histogramme machen diese Verteilung auf einen Blick sichtbar, aber die konkrete Visualisierung ist ein eigenes Thema. Entscheidend ist zunächst das Bewusstsein: Nicht der Durchschnitt zählt, sondern die Form der Verteilung.
Perzentile und Streuung sind analytische Werkzeuge für diejenigen, die das System steuern. Stakeholder brauchen eine einfachere Antwort auf eine einfachere Frage: „Wie oft haltet ihr eure Zusagen ein?“
Einhaltungsquoten messen genau das. Sie erfassen den Anteil der Lieferungen, die innerhalb eines zugesagten oder angestrebten Zeitrahmens erfolgen. Wenn ein Team sich vornimmt, 85 Prozent aller Aufgaben innerhalb von fünfzehn Tagen abzuschließen, dann zeigt die Einhaltungsquote, ob das gelingt. Die Metrik ist unmittelbar verständlich, erfordert keine statistische Vorbildung und beantwortet die Frage, die Stakeholder tatsächlich bewegt.
Wichtig ist, gegen welchen Zielwert gemessen wird. Einhaltungsquoten sind nur so aussagekräftig wie die Zusagen, an denen sie sich orientieren. Wird der Zielwert aus den Perzentilen der historischen Daten abgeleitet, entsteht ein geschlossener Kreislauf: Die Daten bestimmen die Zusage, die Einhaltungsquote zeigt, ob die Zusage realistisch war. Das funktioniert zum Beispiel so: Das 85. Perzentil der Cycle Time liegt bei fünfzehn Tagen. Daraus wird ein Service Level Agreement abgeleitet, das besagt, dass 85 Prozent aller Aufgaben innerhalb von fünfzehn Tagen abgeschlossen werden. Die Einhaltungsquote zeigt dann Monat für Monat, ob dieses SLA eingehalten wird. Wird der Zielwert hingegen politisch gesetzt, etwa weil ein Stakeholder „alles in einer Woche“ erwartet, misst die Einhaltungsquote nicht die Leistung des Teams, sondern die Realitätsferne der Erwartung.
Einhaltungsquoten, als Trend über Zeit betrachtet, zeigen, ob das System stabiler oder instabiler wird. Eine steigende Quote deutet auf Verbesserungen im Prozess hin. Eine sinkende Quote ist ein Frühwarnsignal, das auf wachsende systemische Probleme hinweist, bevor sie sich in verpassten Roadmap-Terminen manifestieren. Der Wert einer Einhaltungsquote liegt also nicht in der absoluten Zahl zu einem bestimmten Zeitpunkt, sondern in der Entwicklung über Wochen und Monate. Ein Team, das von 60 auf 80 Prozent Einhaltung kommt, macht sichtbare Fortschritte, selbst wenn 80 Prozent noch nicht perfekt klingt. Und ein Team, das konstant bei 90 Prozent liegt, hat eine belastbare Grundlage für Stakeholder-Kommunikation, weil es nicht nur behauptet, verlässlich zu liefern, sondern es mit Daten belegen kann.
Eine Warnung ist allerdings angebracht: Einhaltungsquoten können manipuliert werden, wenn die Zusagen vorsichtshalber so großzügig werden, dass sie immer eingehalten werden. Ein Team, das „vier Wochen“ zusagt, obwohl es weiß, dass die meisten Aufgaben in einer Woche fertig sind, hat eine Einhaltungsquote nahe 100 Prozent und trotzdem ein Problem. Die Kombination mit Cycle-Time-Daten verhindert dieses Gaming, weil sichtbar wird, ob die Zusagen zum tatsächlichen Verhalten des Systems passen.
Vorhersagbarkeit zu messen, ist der erste Schritt. Der zweite ist, aus den Messdaten konkrete Prognosen abzuleiten. Dabei gibt es zwei grundsätzlich verschiedene Fragen: „Wann wird dieses einzelne Feature fertig sein?“ und „Wie viele Features schaffen wir bis zu einem bestimmten Termin?“ Die erste Frage lässt sich über Perzentile der Cycle Time beantworten. Die zweite erfordert einen anderen Ansatz, nämlich probabilistisches Forecasting auf Basis von Throughput-Daten.
Die Verbindung ist direkt: Throughput-Daten und Cycle-Time-Verteilungen liefern die Eingangsgrößen für Methoden wie Monte-Carlo-Simulationen, die im Forecasting-Artikel beschrieben werden. Statt einer Punktschätzung produzieren solche Simulationen Wahrscheinlichkeitsverteilungen, also Aussagen wie: „Mit 85 Prozent Wahrscheinlichkeit werden alle zwanzig Features bis zum 15. Juni fertig sein.“ Das Konfidenzlevel entspricht dabei der gleichen Logik wie bei den Perzentilen: Es macht die Unsicherheit explizit, statt sie zu verstecken.
Die Qualität dieser Prognosen hängt direkt davon ab, wie vorhersagbar das zugrunde liegende System ist. Wenn die Cycle Times stark schwanken und der Throughput von Woche zu Woche variiert, produziert auch die beste Simulation breite Ergebnisspannen, die für die Planung wenig nützen. Eine Monte-Carlo-Simulation, die als Ergebnis „irgendwann zwischen März und Oktober“ angibt, mag statistisch korrekt sein, hilft aber keinem Entscheider bei der Quartalsplanung. Enge Ergebnisspannen entstehen nur aus stabilen Systemen mit geringer Variabilität.
Deshalb ist die Reihenfolge entscheidend: Erst messen, ob das System stabil genug für belastbare Prognosen ist. Dann die Stabilität verbessern, wo nötig. Und erst dann die Prognosewerkzeuge einsetzen.
Wer den ersten Schritt überspringt und direkt mit Monte-Carlo-Simulationen beginnt, riskiert präzise aussehende Prognosen auf wackeligem Fundament. Die Simulation produziert in jedem Fall eine Zahl, auch wenn die Eingangsdaten zu volatil sind, um der Zahl zu vertrauen.
Vorhersagbarkeit ist keine Eigenschaft, die ein System hat oder nicht hat. Sie ist ein Spektrum, das sich messen und gezielt verbessern lässt. Die Werkzeuge dafür, Perzentile statt Durchschnitte, Streuung als Diagnoseinstrument, Einhaltungsquoten als Stakeholder-Metrik, sind weder komplex noch teuer. Sie erfordern lediglich, dass die Rohdaten, insbesondere Cycle Time und Throughput, konsequent erfasst werden. Wie diese Daten so aufbereitet und visualisiert werden, dass sie tatsächlich zu besseren Entscheidungen führen, ist ein Thema, das eigene Aufmerksamkeit verdient.
Buchen Sie jetzt Ihre kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.