Flow-Metriken statt Velocity

Wie du mit Cycle Time und Lead Time wirklich vorhersagbar wirst

Problemstellung: Warum Velocity dich in die Irre führt

Velocity misst geschätzten Umfang, nicht Zeit. Sie addiert Story-Points, die ein Team vorab vergibt, und setzt diese Summe als Takt für künftige Planungen. Damit entsteht eine Kennzahl, die auf subjektiven Grössen basiert und deren Referenzrahmen sich ständig verschiebt. Wechselst du das Team, die Schätzskala, den Schnitt der Backlog-Items oder den Workflow, ändert sich die Velocity, ohne dass sich die tatsächliche Lieferfähigkeit zwingend verändert. Du vergleichst dann Schätzkulturen statt Leistungsfähigkeit.

Ersetze Velocity durch Flow-Metriken: Lerne, wie Cycle Time, Lead Time und Monte-Carlo-Forecasts echte Vorhersagbarkeit in agilen Teams schaffen.

Für Stakeholder zählt jedoch der Kalender: Wann ist etwas fertig, wie lange dauert es im Durchschnitt, mit welcher Bandbreite ist zu rechnen. Velocity beantwortet diese Fragen nicht. Sie bildet keine Wartezeiten ab, keine Blockaden im Review, keine Übergaben, keine Abhängigkeiten. Sie ignoriert Reopenings, Kontextwechsel und unplanbare Ereignisse. In Systemen mit Warteschlangen und variabler Ankunftsrate entsteht Vorhersagbarkeit erst aus Zeit- und Flussgrössen, nicht aus Punkten.

Velocity lädt zu Fehlanreizen ein. Wenn Punkte Ziel werden, setzt Goodhart’s Law ein: Teams schneiden Tickets kleiner, verschieben Arbeit in nachgelagerte Schritte oder vermeiden riskante Items, um die Zahl zu stabilisieren. Die Organisation erhält scheinbar gute Kurven, aber keine schnellere Auslieferung. Ein Beispiel: Team A steigert seine durchschnittliche Velocity von 34 auf 46 Punkte pro Sprint, indem es Epics aggressiv zerlegt und Schätzregeln lockert. Die Cycle Time der Tickets bleibt bei median 9 Tagen, die Lead Time steigt wegen längerer Wartephasen auf 18 Tage. Auf Roadmap-Ebene kommt nichts früher an. Die Metrik sieht besser aus, der Kunde spürt keinen Effekt.

Ein weiterer systemischer Fehler: Velocity ist team- und kontextgebunden und daher kaum aggregierbar. Zwei Teams mit je 40 Punkten pro Sprint können völlig unterschiedliche Durchlaufzeiten haben, weil sie andere WIP-Niveaus fahren, andere Engpässe haben oder andere Definitionen für „Done“ nutzen. Für Portfolio-Entscheide ist diese Zahl wertlos. Für Lieferprognosen ebenfalls, weil Punkte keine Zeiteinheiten sind und die Varianz der tatsächlichen Durchlaufzeiten verdecken.

Schliesslich wird Velocity oft als Zusage missverstanden. Ein Sprint-Commitment über 50 Punkte wirkt wie ein Lieferdatum, obwohl es nur eine interne Schätzsumme ist. Bei Abweichungen entsteht Druck, der die Datenqualität weiter verschlechtert: Schätzungen werden taktisch, nicht informativ. Damit verliert die Organisation das einzige, was sie für Prognosen braucht: belastbare, beobachtbare Zeiten von Start bis Fertig.

Kurz: Velocity optimiert die Darstellung, nicht den Fluss. Sie beantwortet weder die zentrale Managementfrage „Wann?“ noch reduziert sie Unsicherheit. Wer Vorhersagbarkeit will, misst reale Zeit über den gesamten Weg der Arbeit, macht Wartezeiten sichtbar und steuert WIP und Engpässe. Genau hier setzen Cycle Time und Lead Time an.

Begriffe und Messgrenzen sauber definieren

Vorhersagbarkeit entsteht, wenn du Zeit über klar definierte Messgrenzen beobachtest. Der erste Schritt ist daher eine saubere Trennung der Begriffe und ihrer Start- und Endpunkte.

Lead Time misst die Wartezeit aus Sicht des Kunden. Sie beginnt, wenn ein Bedarf sichtbar wird (Eingang als Anfrage, Ticket oder Bestellung) und endet mit Auslieferung in Produktion oder anderweitig nutzbarer Bereitstellung. Lead Time beantwortet die Frage: Wie lange wartet der Kunde von „Ich brauche das“ bis „Ich kann es nutzen“.

Cycle Time misst die Durchlaufzeit der Umsetzung. Sie beginnt, wenn Arbeit am Item tatsächlich startet (Statuswechsel auf „In Arbeit“ oder gleichwertig) und endet mit „Fertig“ gemäss Definition of Done. Cycle Time beantwortet die Frage: Wie lange braucht das System, um begonnenes Arbeitspaket fertigzustellen.

Diese beiden Grössen sind nur belastbar, wenn du die Messgrenzen präzise festlegst. Definiere je Workflow-State, ob er aktiv (Wertschöpfung) oder wartend (Queue) ist, und verankere prozessual, welche Statuswechsel den Start- und Endzeitpunkt auslösen. Dokumentiere das in einer knappen Policy:
Start Cycle Time = erster Eintritt in einen aktiven State;
Ende Cycle Time = Eintritt in „Done“ gemäss Definition of Done;
Start Lead Time = Eingang als qualifizierte Kundenanfrage;
Ende Lead Time = produktiv nutzbar.
Reopenings verlängern die bestehende Cycle Time; sie erzeugen kein neues Item. Blockierte Zustände zählen als wartend und damit zur Cycle Time sowie zur Lead Time.

WIP (Work in Progress) ist die Anzahl nicht fertiggestellter Items im System (alle Status ausser „Done“). Throughput ist die Anzahl fertiggestellter Items pro Zeiteinheit (pro Woche oder Sprint). Flow Efficiency ist der Anteil aktiver Bearbeitungszeit an der gesamten Durchlaufzeit: aktive Stunden/Tage dividiert durch Cycle Time. Damit werden Liege- und Übergabezeiten sichtbar.

Zwischen diesen Grössen gilt Little’s Law für stabile Systeme:
WIP = Throughput × Cycle Time (im Mittel).
Es zwingt zu Konsistenz. Wenn deine gemessene Cycle Time sinkt, ohne dass WIP oder Throughput plausibel reagieren, stimmt die Messgrenze oder die Datenerfassung nicht.

Messdisziplin entscheidet über Aussagekraft. Lege fest:

1. Granularität der Items. Miss auf einer konstanten Ebene (z. B. Produkt-Backlog-Item, nicht mal PBI, mal Subtask).

2. Zeiteinheit. Für Kundensicht eignen sich Kalendertage, für interne Engpassanalyse oft Arbeitstage. Vermische beides nicht.

3. Umgang mit Ausreissern. Markiere Blocker-Ereignisse explizit; entferne keine Daten, sondern analysiere Ursachen.

4. Definitionen. DoR steuert den Eintritt in die Lead Time nicht; der Eintritt ist die Kundenanfrage. DoD steuert das Ende; keine „quasi fertig“-Zustände.

5. Klassen von Arbeit. Kennzeichne Expedite, Fixed Date, Standard, Intangible. Unterschiedliche Klassen haben unterschiedliche Verteilungen; mische sie nicht in einer einzigen Zusage.

Für die spätere Kommunikation brauchst du robuste Kennwerte. Verwende Perzentile statt Mittelwerte. Beispiel: „85 % unserer Items liegen bei Cycle Time ≤ 8 Tagen“ ist eine belastbare Service Level Expectation (SLE). Hinterlege P50/P85/P95 für Cycle Time und Lead Time getrennt, pro Klasse von Arbeit. Ergänze WIP-Obergrenzen je aktivem State, damit du Flow aktiv steuern kannst.

Erst wenn diese Messgrenzen klar und konsistent umgesetzt sind, lassen sich Charts, SLEs und Forecasts ohne Interpretationsspielraum aufsetzen. Ohne diese Grundlagen erzeugen Metriken Scheingenauigkeit. Mit ihnen wird Zeit messbar, vergleichbar und vorhersagbar.

Datenerhebung aus dem Tooling – ohne Daten keine Vorhersage

Vorhersagbarkeit entsteht erst, wenn Zeitstempel zuverlässig erfasst werden. Lege deshalb den Workflow technisch so aus, dass Beginn, Wartephasen und Abschluss eines Items automatisch dokumentiert werden. Entscheidend ist die Abbildung deiner Messgrenzen im System: Der Eintritt in den ersten aktiven Zustand markiert den Start der Cycle Time, der Übergang in „Done“ das Ende. Die Lead Time beginnt mit Eingang der Kundenanfrage und endet mit produktiver Nutzbarkeit. Diese Logik muss sich in Statusübergängen, Feldern und Automationen widerspiegeln, damit jede Auswertung reproduzierbar bleibt.

Beginne mit einem eindeutigen Mapping aller Status auf drei Kategorien: wartend (Queues wie „Ready“, „Selected“, „On Hold“), aktiv (wertschöpfende Bearbeitung wie „In Arbeit“, „Review“, „Test“) und fertig („Done/Live“ gemäss Definition of Done). Hinterlege diese Kategorisierung nicht nur im Teamhandbuch, sondern im Tool selbst. Richte eine Automation ein, die beim ersten Eintritt in einen aktiven Status einmalig ein Feld „cycle_start_at“ stempelt. Beim Eintritt in „Done“ füllt die gleiche Logik „cycle_end_at“. Für die Lead Time verwende „lead_start_at“ beim qualifizierten Eingang und „lead_end_at“ bei produktiver Verfügbarkeit. Reopenings ändern den Start nicht; sie verlängern die bestehende Cycle Time. Blockaden erfässt du als Intervalle: Beim Setzen des Blocker-Merkmals stempelst du „blocked_from“, beim Entfernen „blocked_to“; die Differenzen summierst du zu „blocked_minutes“. So wird Flow Efficiency später messbar, ohne manuelle Nacharbeit.

Ergänze minimale Felder für die spätere Segmentierung: „class_of_service“ (Standard, Fixed Date, Expedite, Intangible), „work_type“ (Bug, Feature, Chore), „product/stream“, sowie eine eindeutige Item-Ebene (z. B. Product Backlog Item). Vermeide gemischte Granularität. Messe nicht einmal auf Feature- und einmal auf Subtask-Ebene. Entscheide dich für genau eine Ebene als Referenz und halte sie durch. Epics dienen der Planung, nicht der Zeitmessung; Subtasks sind interne Arbeitsteilung, die die Durchlaufzeit des übergeordneten Items nur aufteilt, nicht verkürzt.

Für bestehende Tickets brauchst du einen historischen Backfill. Ziehe dafür die Status-Historie heran und berechne rückwirkend „cycle_start_at“ und „cycle_end_at“ gemäss deiner Kategorisierung. Ermittle Blocker-Intervalle aus Kennzeichnungen oder Kommentaren, wenn vorhanden; wenn nicht, beginne ohne diese Dimension und ergänze sie ab Stichtag prospektiv. Wähle einen Zeitraum, der breit genug für stabile Verteilungen ist, typischerweise 90 bis 180 Kalendertage. Kürzere Fenster erzeugen statistisches Rauschen, längere verwaschen Prozessänderungen.

Achte auf Zeitdisziplin. Speichere Zeitstempel in UTC und rechne erst in der Visualisierung in lokale Zeit um. Dokumentiere, ob du in Kalendertagen oder Arbeitstagen rechnest, und bleibe konsistent. Erstelle einen Feiertagskalender pro Region, wenn du Arbeitstage verwenden willst, oder bleibe bei Kalendertagen, wenn du die Kundensicht abbildest. Prüfe auf systematische Fehler: fehlende „cycle_start_at“-Stempel bei Items, die „Done“ sind; negative Laufzeiten durch manuelle Statussprünge; doppelte Starts durch Hin- und Herwechseln. Solche Datenfehler korrigierst du mit klaren Regeln, nicht durch Löschen ganzer Tickets.

Definiere einen Exportpfad in ein Auswertungstableau oder Data Warehouse. Jede Zeile entspricht einem Item, die Kernspalten lauten: item_id, lead_start_at, lead_end_at, cycle_start_at, cycle_end_at, blocked_minutes_total, class_of_service, work_type, product/stream, created_at, closed_reason (Done, Cancelled, Duplicate). Ergänze eine WIP-Aging-Sicht: Für jedes nicht abgeschlossene Item berechnest du „age_in_progress“ als aktuelle Zeit minus „cycle_start_at“. Das ermöglicht aktives Steuern, bevor Durchlaufzeiten entgleisen.

Validiere die Daten mit einfachen Konsistenzprüfungen. Berechne für einen Monat den mittleren Throughput pro Woche, die mittlere Cycle Time und das mittlere WIP. Prüfe anschliessend Little’s Law im Mittel: WIP ≈ Throughput × Cycle Time. Erlaubt sind Abweichungen durch Saison und Batchlieferungen, nicht jedoch systematische Diskrepanzen. Vergleiche zudem die Summe deiner aktiven und wartenden Zeitsegmente mit der gemessenen Cycle Time; die Differenz muss null sein. Stimmen diese Identitäten nicht, stimmt die Implementierung nicht.

Lege zuletzt Betriebspolicies fest, die die Datenqualität sichern: Statuswechsel nur durch die Rolle, die den Schritt verantwortet; kein Direktwechsel von „Backlog“ nach „Done“; Blockaden werden sofort markiert; bei Reopenings wird nie ein neuer Start gestempelt; bei Cancelled-Items wird „lead_end_at“ gesetzt, „cycle_end_at“ bleibt leer. Führe ein wöchentliches Data-Review ein, in dem stichprobenartig zehn abgeschlossene und zehn aktive Items gegen den Workflow geprüft werden. Miss auf dieser Basis deine „vorhersagbarkeit mit cycle time und lead time in agilen teams“; ohne stabile Datenerfassung bleibt jede Prognose Spekulation. Mit ihr wird jede spätere Visualisierung und jeder Forecast belastbar.

Visualisieren, um Muster zu erkennen

Ein Flusssystem wird erst durch wenige, richtige Charts lesbar. Jedes Chart beantwortet eine konkrete Managementfrage. Gemeinsam ergeben sie eine belastbare Geschichte über Stabilität, Engpässe und Vorhersagbarkeit. Die Basis bildet eine saubere Zeitachse mit abgeschlossenen Items, konsistente Messgrenzen und Perzentile statt Mittelwerte.

Cycle-Time-Scatterplot: Wie lange dauern einzelne Tickets?
Auf der x-Achse liegen Abschlussdaten, auf der y-Achse die Cycle Time pro Item. Zeichne die Perzentile P50, P85 und P95 als horizontale Linien ein. Ein aufwärts gerichteter Keil zeigt zunehmende Varianz und damit schwindende Vorhersagbarkeit. Ein konstanter „Bauch“ oberhalb P85 markiert systematische Blockaden oder einen überlasteten Schritt. Ein Abfall der Medianlinie nach einem Prozesswechsel belegt Wirkung. Einzelne Ausreisser interessieren weniger als Muster: Wiederkehrende „Bänder“ auf bestimmten Laufzeiten deuten auf fixe Wartefenster (z. B. wöchentliche Freigaben). Dieses Chart liefert die Kennzahl für SLEs: „85 % der Items ≤ 8 Tage“.

Control Chart: Ist das System statistisch stabil?
Das Control Chart zeigt die zeitliche Entwicklung der Cycle Time inklusive Obergrenze (etwa P95) und Mittel-/Medianlinie. Stabilität bedeutet, dass Punkte innerhalb der Grenzen ohne Serieneffekte liegen. Serien gleicher Richtung, Cluster nahe der Obergrenze oder wiederholte Grenzverletzungen weisen auf Sonderursachen hin: Personalengpass, Umstellung des Testverfahrens, Batch-Freigaben. Ohne Stabilität sind Prognosen schwach; zuerst Ursachen identifizieren und abstellen, dann erneut messen.

Cumulative Flow Diagram (CFD): Wo staut sich Arbeit?
Das CFD kumuliert die Anzahl Items je Status über die Zeit. Die vertikale Distanz zwischen „In Arbeit“ und „Done“ entspricht dem WIP; die Steigung der „Done“-Kurve ist der Throughput. Parallel verlaufende, gleichmässige Bänder stehen für Fluss. Ein auseinanderlaufendes Band in „Review“ oder „Test“ signalisiert einen Engpass. Eine abflachende „Done“-Kurve zeigt sinkenden Throughput. Die horizontale Distanz zwischen Eintritt und Austritt eines durchschnittlichen Items approximiert die Cycle Time; idealerweise korrespondiert sie mit dem Scatterplot. Mit dem CFD identifizierst du, wo WIP-Limits und Policies ansetzen müssen.

WIP-Aging-Chart: Welche aktiven Tickets geraten ausser Kontrolle?
Dieses Chart listet alle aktiven Items und ihre bisherige Zeit im System, gruppiert nach Status. Lege die P50/P85-Linien der historischen Cycle Time darüber. Alles, was die P85-Linie zu überholen droht, verdient sofortige Aufmerksamkeit. Damit steuerst du präventiv, statt hinterher zu erklären, warum SLEs verfehlt wurden.

Throughput-Run-Chart und Histogramme: Wie breit ist die Verteilung?
Das Run-Chart zeigt abgeschlossene Items pro Woche. Stabile Lieferfähigkeit äussert sich als schmale Schwankungsbreite ohne harte Einbrüche. Ein Histogramm der Cycle Time macht Klassen von Arbeit sichtbar: Ein hoher Anteil extrem kurzer Tickets neben einer langen „Tail“ weist auf künstliches Zerschneiden hin, das die Kennzahlen verschönt, aber keine echte Beschleunigung bringt.

Perzentil-basierte SLEs: Zusagen ohne Wunschdenken
Leite Service Level Expectations aus realen Daten der letzten 90 bis 180 Tage ab. Formuliere sie pro Klasse von Arbeit, nicht pauschal: „Standard: 85 % ≤ 8 Tage; Fixed Date: Termin nach Vereinbarung; Expedite: sofort, begrenzt auf ein Item je Stream.“ Visualisiere die Einhaltung als einfaches Gauge oder als Anteil eingehaltene SLEs pro Woche. Passe SLEs nur nach belegter, nachhaltiger Prozessänderung an, nie aus politischen Gründen.

Eine konsistente Story auf einer Seite
Oben rechts: SLEs (P85/P95) für Cycle Time und Lead Time. Links: Cycle-Time-Scatterplot mit Perzentillinien. Mitte: CFD mit markiertem Engpass. Rechts: WIP-Aging mit Heute-Stand. Unten: Throughput-Run-Chart. Mit dieser Komposition beantwortest du die Kernfragen zur vorhersagbarkeit mit cycle time und lead time in agilen teams: Wie lange dauert es, wie stabil liefern wir, wo verlieren wir Zeit, welche Tickets brauchen jetzt Intervention. Charts werden damit zum Steuerungsinstrument, nicht zur Dekoration.

Forecasting, das hält: von Einzel-Tickets bis Releases

Vorhersagen basieren auf beobachteter Zeit, nicht auf Punkten. Die einfachste belastbare Zusage auf Item-Ebene lautet: „Wenn wir heute starten, liegt die Cycle Time für Standard-Arbeit mit 85-prozentiger Wahrscheinlichkeit bei höchstens X Tagen.“ Diese Aussage stützt sich auf die Perzentilverteilung der vergangenen 90 bis 180 Tage, getrennt nach Klasse von Arbeit. Die Due-Date-Herleitung ist trivial und erklärbar: Due-Date = Startdatum + P85(Cycle Time | Klasse). Für Expedite gilt ein separates, streng limitiertes Policy-Fenster; für Fixed-Date-Arbeit wird die Zusage rückwärts gerechnet: spätester Start = Liefertermin − P85(Lead Time), inklusive Puffer für Abnahmen. Diese Regeln schaffen vorhersagbarkeit mit cycle time und lead time in agilen teams ohne Modellakrobatik und sind gegenüber Stakeholdern transparent.

Sobald es um Bündel geht—ein kleines Release, eine Inkrementliste, ein Epic mit N Items—reichen Einzel-Perzentile nicht mehr. Hier liefert Monte-Carlo-Sampling robuste Bandbreiten, ohne Annahmen über Normalverteilungen. Für ein Datums-Forecast („Bis wann ist der Umfang fertig?“) verwendest du die empirische Throughput-Verteilung. Du nimmst die abgeschlossenen Items pro Woche (oder pro Tag), bildest daraus eine Stichprobe mit Zurücklegen und addierst in jeder Simulation so lange, bis die Zielmenge N erreicht ist. Jede Simulation ergibt eine Kalenderdauer; über viele Wiederholungen—typisch 10 000 Läufe—entsteht eine Verteilung möglicher Fertigstellungsdaten. Daraus kommunizierst du P50, P85 und P95 als konkrete Daten. Für einen Scope-Forecast („Wie viel schaffen wir bis Datum D?“) drehst du die Logik um: Du summierst in jeder Simulation den gezogenen Throughput bis D und erhältst eine Verteilung erreichbarer Stückzahlen; daraus leitest du ab, welcher Umfang mit 85 % Wahrscheinlichkeit lieferbar ist.

Monte-Carlo lässt sich auch auf Einzel-Items anwenden, wenn du nicht den P85 der Cycle Time als fixe Zahl nutzen willst. Du ziehst in jeder Simulation eine Cycle-Time-Dauer aus der empirischen Item-Verteilung (gleiche Klasse von Arbeit, gleicher Stream), addierst sie auf das Startdatum und erhältst eine Verteilung möglicher Due-Dates. Dieser Ansatz bildet die lange „Tail“ realitätsnäher ab als der nackte Perzentilwert und eignet sich, wenn dein Portfolio stark heterogen ist oder wenn Blockerhäufigkeit schwankt.

Zwei Voraussetzungen entscheiden über die Qualität der Vorhersage. Erstens Stabilität: Die Verteilung der Cycle Time und des Throughput in deinem Messfenster darf nicht durch einen Prozessbruch verzerrt sein. Ein Wechsel im Testverfahren, ein neuer Gate-Schritt oder die Einführung strengerer Review-Policies erzeugen andere Verteilungen. In diesem Fall trennst du die Daten in „vor“ und „nach“ und forecastest nur mit dem aktuellen Regime. Zweitens Segmentierung: Forecasts werden pro Klasse von Arbeit, pro Produkt/Stream und—wenn relevant—pro Ticket-Typ gerechnet. Das reduziert Mischverteilungen, die Bandbreiten künstlich aufblähen.

Kommunikation erfolgt als Bandbreite statt Punktwert. Ein konkretes Beispiel: „Für den Umfang von 42 Items zeigt das Modell P50 am 14. November, P85 am 28. November, P95 am 9. Dezember.“ Entscheide dich bewusst für ein Konfidenzniveau—im operativen Alltag hat sich P85 bewährt, weil es Risiko und Handhabbarkeit ausbalanciert. Ergänze eine einfache Entscheidungslogik: Wenn P85 hinter dem gewünschten Zieldatum liegt, stehen drei Hebel zur Wahl—Scope reduzieren, Batching vermeiden und WIP senken, zusätzliche, qualifizierte Kapazität am Engpass. Der erste Hebel wirkt sofort, der zweite mittelfristig, der dritte nur, wenn er den tatsächlichen Engpass adressiert; zusätzliche Entwickler im Nicht-Engpass verbessern die Vorhersage nicht.

Backtesting schützt vor Wunschdenken. Du prüfst rückwirkend, wie gut deine Zusagen die Realität abbilden. Für jedes Item, das vor 30 Tagen gestartet und inzwischen abgeschlossen ist, berechnest du das damals gültige P85-Due-Date und zählst, wie oft es eingehalten wurde. Liegt die Trefferquote deutlich unter 85 %, ist das System unterkalibriert; du analysierst Ursachen: WIP-Spitzen, neue Warteschritte, steigende Blockeranteile. Ergänze zwei Metriken: Kalibrationsfehler (Soll-minus-Ist-Trefferquote) und Schärfe (Bandbreite P95−P50). Ziel ist eine kleine Kalibrationsabweichung bei möglichst schmaler Bandbreite. Wird die Bandbreite zu gross, fliessen zu viele heterogene Klassen in eine Verteilung ein oder dein System ist instabil.

Annahmen und Grenzen gehören offen auf den Tisch. Monte-Carlo nimmt keine Normalität an, aber es setzt voraus, dass die jüngste Vergangenheit informativ für die nahe Zukunft ist. Saisonale Effekte, geplanter Tech-Cutover oder ein neues Abnahmeverfahren brechen diese Annahme. Dann definierst du ein neues Messfenster und startest dein Backtesting neu. Korrelationen zwischen Items—z. B. gemeinsame Abhängigkeit von einer Freigaberunde—verbreitern die tatsächliche Varianz. Hier hilft es, nicht „fertig“ als Deployment zu modellieren, sondern die gemeinsame Abnahme explizit als eigener Schritt mit eigener Verteilung abzubilden.

Auf Portfolio-Ebene kombinierst du beides: Einzel-Due-Dates für geschäftskritische Tickets und Throughput-basierte Bandbreiten für Bündel. Du verknüpfst die Zusagen mit Service Level Expectations: „Standard: P85 ≤ 8 Tage Cycle Time“, ergänzt um eine Portfolio-Policy: „Mindestens 80 % der Standard-Tickets halten die SLE; Abweichungen führen zu WIP-Reduktion und Engpass-Entlastung.“ Die Einhaltung der SLEs zeigst du wöchentlich; Forecast-Kurven aktualisierst du mit rollierendem Fenster. So entsteht ein geschlossener Regelkreis: messen, forecasten, liefern, zurückspiegeln, justieren.

Der Nutzen liegt in der Entscheidungsqualität. Stakeholder erhalten keine abstrakte Velocity-Zahl, sondern datengestützte Antworten auf „Wann“ und „Wie viel“. Teams steuern proaktiv über WIP und Policies. Abweichungen werden früh sichtbar und quantifizierbar. So wird Vorhersage zur Betriebspraxis und nicht zur Präsentationsfolie.

Operativ steuern: Policies, WIP-Limits und Flow Efficiency

Vorhersage entsteht im Alltag, nicht im Reporting. Du brauchst klare Regeln, die den Fluss jeden Tag steuern: Was darf ins System, wie viel gleichzeitig, in welcher Reihenfolge, mit welchen Rechten für Ausnahmen und mit welchen Eskalationen bei Blockaden. Diese Regeln heissen Policies. Sie sind öffentlich, kurz, messbar und werden eingehalten.

Zulassung und Reihenfolge. Arbeit gelangt nur über eine Replenishment-Entscheidung ins System. Die Auswahl folgt einer sichtbaren Priorisierungsliste, getrennt nach Klassen von Arbeit: Standard, Fixed Date, Expedite, Intangible. Innerhalb einer Klasse gilt FIFO. Expedite existiert als ein simultan erlaubtes Ticket je Stream, mit dokumentierter Geschäftsbegründung und Nachreview. Fixed Date erhält rückwärts geplante Startzeitpunkte aus der Lead-Time-Verteilung. Intangibles laufen nur, wenn Standard-WIP unter Ziel liegt.

WIP-Limits als Systembremse. Setze WIP-Limits auf System- und auf Schritt-Ebene. Systemlimite: Richtwert Personen × 1.5 Items, gerundet. Beispiel: 6 Personen → WIP 9. Schritt-Limiten verhindern lokale Staus, etwa „Review ≤ 3“. Die Limiten sind hart. Wird die Limite erreicht, startet niemand Neues, bis etwas fertig ist. Du leitest Limiten aus Zielzeiten ab: Mit Little’s Law gilt WIP = Throughput × Cycle Time. Willst du die mediane Cycle Time von 12 auf 8 Tage senken, halbiere nicht die Welt, sondern reduziere WIP proportional und halte die Limite konsequent ein.

Pull statt Push. Niemand verteilt Arbeit. Teams ziehen das nächste Item aus der priorisierten Schlange, sobald Kapazität frei wird. „Teilweise angefangen“ zählt als WIP und blockiert Pull. Persönliche Multitasking-Experimente sind Systemschäden: ein Item pro Person in aktiven Schritten, Pairing und Mobbing explizit erlaubt, um Engpässe zu entlasten.

Flow Efficiency gezielt erhöhen. Flow Efficiency = aktive Bearbeitungszeit / Cycle Time. Du erhöhst sie nicht durch schnelleres Tippen, sondern durch kürzere Wartezeiten. Vier Hebel wirken sofort:

1. Review-SLA: Code- oder Business-Reviews innerhalb 24 Stunden, Testfreigabe innerhalb 48 Stunden, gemessen und sichtbar.

2. Übergaben bündeln: Übergabepunkte minimieren, Verantwortungen verschieben statt Tickets.

3. Automatisieren, was blockiert: Test- und Deploy-Pfade automatisieren, Definition of Done verlangt lauffähige Automation.

4. Swarming: Wenn ein Item den P85-Aging-Wert zu überschreiten droht, bündelt das Team Kapazität darauf, bis es fertig ist. Keine neuen Starts, bevor dieses Item die Linie unterschreitet.

Blocker-Management als tägliche Pflicht. Jeder Blocker erhält einen Zeitstempel von-bis und einen Grundcode (z. B. „Externe Abnahme“, „Umgebungsfehler“, „Entscheid fehlt“, „Abhängigkeit Team X“). Tägliche Blocker-Runde: nur blockierte Items, nur Beseitigungsentscheidungen. Wöchentliche Pareto-Auswertung der Blocker-Minuten: Die Top-3-Gründe erhalten eine Gegenmassnahme mit Owner und Termin. Wenn „Review wartet“ die Liste anführt, ist das keine Moralfrage, sondern eine Kapazitäts- und Policy-Frage: Review-Limite senken, feste Review-Zeitfenster einführen, Pair-Review etablieren.

Aging- und SLE-Disziplin. WIP-Aging-Charts hängen sichtbar. Jedes aktive Item wird gegen die historische Cycle-Time-Verteilung gespiegelt. Zwei Schwellen steuern dein Handeln: P50 = gelb (prüfen, ob ein Hindernis droht), P85 = rot (Swarm oder Eskalation). SLEs sind Verträge mit dir selbst: „85 % der Standard-Items ≤ 8 Kalendertage Cycle Time“. Verfehlungen lösen Ursache-Suche und WIP-Reduktion aus, nicht kosmetische Umbauten am Board.

Portfolio-Regeln ohne Velocity. Streams teilen sich eine Portfolio-WIP-Limite für gleichzeitige Epics/Initiativen. Expedite hat ein Quotenbudget pro Quartal. Fixtermine werden frühzeitig rückwärts geplant; wenn der späteste Start im roten Bereich liegt, wird Scope reduziert oder der Engpass entlastet. Keine Teamvergleiche, keine Punktumrechnung. Die Steuergrösse ist Durchlaufzeit je Klasse und Throughput pro Zeitraum.

Rollen und Verantwortungen. Der Product Owner verantwortet Priorität und Klassifizierung, nicht die Kapazitätssteuerung. Das Team verantwortet WIP, Aging und SLE-Einhaltung. Die Führung schafft Voraussetzungen: ungestörte Review-Zeitfenster, Zugriff auf Umgebungen, schnelle Entscheidungen an Engpässen. Operative Kennzahlen gehören in das Weekly der Führung: SLE-Trefferquote, Median- und P85-Cycle-Time, Blocker-Pareto, WIP-Entwicklung.

Release- und Batchpolitik. Kleine, häufige Releases verkürzen Lead Time, entschärfen Risiko und reduzieren Korrelation zwischen Items. Lege maximale Batchgrössen fest (z. B. höchstens 5 Items pro Release) und eine maximale Stauzeit nach „Fertig“ bis Deployment (z. B. 48 Stunden). „Fertig“ ohne Auslieferung ist Warteschlange im Versteck.

Interrupt- und Support-Lanes. Unplanbare Produktionsarbeiten laufen in einer separaten Lane mit eigenem WIP-Limit und eigener SLE. Diese Lane erhält dedizierte Rotationskapazität, damit Standardfluss nicht kollabiert. Jedes Interrupt-Item ist ticketiert; „Dark Work“ ist verboten, sonst bricht jede vorhersagbarkeit mit cycle time und lead time in agilen teams.

Experimentieren unter Kontrolle. Prozessänderungen laufen als Experimente mit Hypothese und Messgrösse: „Wenn wir Review-SLA auf 24 h setzen, sinkt P85-Cycle-Time von 10 auf 8 Tage in 4 Wochen.“ Nach Ablauf: messen, behalten oder verwerfen. Keine Dauerbaustelle am Prozess, kein Glaubenskrieg, nur Evidenz.

Einführungsreihenfolge mit Wirkung in sechs Wochen.
Woche 1: Messgrenzen fixieren, WIP zählen, Limiten setzen.
Woche 2: Aging-Board und Blocker-Stamp einführen, Review-SLA festlegen.
Woche 3: Swarm-Regel am P85-Schwellenwert, Interrupt-Lane aktivieren.
Woche 4: Schritt-Limiten justieren, Pareto der Blocker umsetzen.
Woche 5: Release-Batchlimit, maximale Stauzeit bis Deployment, Automationslücken schliessen.
Woche 6: SLE kalibrieren, Backtesting starten, Portfolio-WIP verankern.

So steuerst du Fluss als Betriebspraxis. Policies und Limiten verhindern Stau, Aging und Blocker-Management erzeugen frühe Eingriffe, SLAs und Automationen erhöhen Flow Efficiency. Aus diesen Regeln folgen stabilere Verteilungen, engere Bandbreiten und belastbare Zusagen—ohne Velocity, mit nachvollziehbarer Zeit.

Einführung in der Praxis: Fahrplan, Antipatterns, Governance

Der Wechsel von Velocity zu Flow-Metriken gelingt, wenn du ihn als Organisationsänderung aufziehst: klare Verantwortung, schlanker Pilot, sichtbare Ergebnisse, verbindliche Regeln. Die technische Messung ist gelöst; jetzt geht es um Einführung, Betrieb und Skalierung.

Fahrplan in sechs Wochen mit klaren Ergebnissen
Woche 1: Kick-off und Messgrenzen. Du stellst den Zweck vor: Vorhersagen in Kalendertagen, SLEs statt Punkte. Du beschliesst die Messgrenzen (Start/Ende für Lead und Cycle Time), definierst die Klassen von Arbeit und richtest die Statuskategorien wartend/aktiv/fertig ein. Ergebnis: freigegebene Policy, lauffähige Zeitstempel in deinem Tool, ein Data-Dictionary mit Feldnamen und Definitionen.

Woche 2: Datenernte und Qualität. Du ziehst 90–180 Tage Historie, rechnest Backfill und prüfst Konsistenz (Little’s Law, negative Zeiten, Reopenings). Du markierst Blocker sauber. Ergebnis: erste saubere Item-Tabelle mit lead_*, cycle_*, blocked_minutes_total, class_of_service, work_type.

Woche 3: Visualisierung und erste SLE. Du baust Cycle-Time-Scatterplot, CFD, WIP-Aging, Throughput-Run-Chart. Du kalibrierst eine erste SLE pro Klasse („Standard: P85 ≤ X Tage Cycle Time“). Ergebnis: ein einseitiges Dashboard, das die Vergangenheit erklärt und eine verständliche SLE formuliert.

Woche 4: Operative Steuerung. Du setzt System- und Schritt-WIP-Limiten, führst Review-SLAs ein, aktivierst eine Interrupt-Lane mit eigener Limite. Swarming ab P85-Aging wird zur Pflicht. Ergebnis: sichtbare Eingriffe im Fluss, weniger Stau, erste Reduktion der Varianz.

Woche 5: Forecasting und Backtesting. Du rechnest Monte-Carlo für ein konkretes Bündel und kommunizierst P50/P85/P95 als Daten. Parallel startest du Backtesting auf Item-Ebene (Trefferquote gegen P85). Ergebnis: belastbare Termine mit Bandbreiten plus eine Kalibrationszahl.

Woche 6: Entscheide und Skalierung. Du ziehst Bilanz: SLE-Trefferquote, Median- und P85-Cycle-Time, Top-Blocker, WIP-Entwicklung. Du beschliesst, welche Policies du behältst, welche Limiten du nachschärfst, und planst die Übernahme auf den nächsten Stream. Ergebnis: ein dokumentierter Standard und ein Rollout-Plan.

Antipatterns, die du aktiv verhinderst

1. Metriken-Theater. Charts ohne Entscheidungen. Gegenmittel: Jede Metrik erhält eine Steuerregel („Wenn P85 verfehlt, dann WIP senken und Blocker-Pareto umsetzen“).

2. Punkte-Umrechnung. Story-Points auf Tage mappen. Gegenmittel: Punkte komplett aus Forecast- und Führungsdialogen entfernen; nur Zeit und Durchsatz kommunizieren.

3. Ticket-Splitting für schöne Zahlen. Items werden künstlich klein, ohne Wartezeiten zu reduzieren. Gegenmittel: Mindest-Item-Schnitt definieren und Flow Efficiency messen; wenn Wartezeit dominiert, hilft Zerlegen nicht.

4. Reopen = Neustart. Cycle Time wird bei Wiedereröffnung genullt. Gegenmittel: Reopen verlängert die bestehende Zeit; die Historie bleibt sichtbar.

5. Durchschnitt statt Perzentile. Mittelwerte verschleiern die Tail. Gegenmittel: SLEs immer P50/P85/P95; keine Mean-basierte Zusage.

6. Teamvergleiche. Velocity- oder Cycle-Time-Rankings. Gegenmittel: Vergleiche nur innerhalb eines Streams über die Zeit; zwischen Teams nur Prozesse und Policies vergleichen.

7. Klassen mischen. Expedite und Standard in einer Verteilung. Gegenmittel: strikte Segmentierung nach Klasse von Arbeit und, wenn nötig, nach Stream/Produkt.

8. „Fertig“ ohne Lieferung. Done ist nicht deployt. Gegenmittel: Deployment als fester Prozessschritt mit eigener SLE (max. 48 Stunden Stauzeit bis Produktion).

9. Dark Work. Ungetrackte Supportarbeit. Gegenmittel: Interrupt-Lane mit WIP-Limit und SLE; jede Arbeit hat ein Ticket.

10. Einmalige Bereinigung, kein Betrieb. Initiale Messung, danach Stillstand. Gegenmittel: wöchentliches Data-Review und monatliche SLE-Überprüfung als feste Termine.

Governance: leicht, verbindlich, auditierbar

• Single Source of Truth. Eine Datenpipeline erzeugt die Item-Tabelle. Versioniert, reproduzierbar, dokumentiert. Kein Excel-Shuffle.

• Data-Dictionary. Definitionen für cycle_start_at, cycle_end_at, lead_start_at, lead_end_at, Blocker-Codes, Klassen von Arbeit. Änderungen nur via Change-Log.

• SLE-Politik. SLEs gelten pro Klasse/Stream, werden monatlich überprüft und nur nach belegter Prozessänderung angepasst. Jede Anpassung mit Vorher/Nachher-Chart.

• Backtesting-Pflicht. Monatliche Kalibrationsprüfung: Trefferquote gegen P85, Schärfe (P95−P50). Unterlaufene Quote → Gegenmassnahmen mit Termin.

• WIP-Governance. System- und Schritt-Limiten sind Teil der Arbeitsordnung. Überziehungen werden im Daily adressiert, nicht wegerklärt.

• Blocker-Management. Standardisierte Codes, wöchentliches Pareto, Top-3-Massnahmen mit Owner.

• Rollenklärung. Product Owner verantwortet Priorität und Klasse; Team steuert WIP, Aging und SLE; Führung beseitigt organisatorische Engpässe (Umgebungen, Freigaben, Kapazität am Engpass).

• Transparenz. Dashboard öffentlich für Team, Führung, Stakeholder. Keine Sonder-Excel für Führungssitzungen, keine abweichenden Zahlenwelten.

• Compliance und Datenschutz. Personenbezogene Leistungsdaten werden nicht veröffentlicht; die Steuerung erfolgt auf System- und Item-Ebene. Zeitstempel in UTC, Aufbewahrungsfristen definiert.

Skalierung über mehrere Teams
Starte mit einem Stream, der echte Abhängigkeiten und Produktionsreife abbildet. Rolle anschliessend in Wellen aus: pro Welle gemeinsame Definitionen, identischer Dashboard-Rahmen, lokale Policies nach Engpass. Portfolio-WIP begrenzt parallele Initiativen. Fixtermine werden zentral rückwärts geplant, basierend auf den jeweiligen Lead-Time-Verteilungen. Expedite erhält eine Quote pro Quartal. Gemeinsame Rituale: monatliches Flow-Forum für Product Owner und Team-Coaches, in dem SLE-Treffer, Blocker-Pareto und Portfolio-WIP diskutiert werden. Ziel ist Kohärenz, nicht Uniformität.

Kommunikation nach aussen
Stakeholder erhalten Antworten in Zeit, nicht in Punkten: „Standard-Items: P85 Cycle Time 8 Tage; Release-Umfang N: P85-Fertigstellung 28. November; Einhaltung der SLE in den letzten vier Wochen: 82 %.“ Wenn die Zahl sinkt, erklärst du Ursache und Massnahme, nicht Ausreden. So baust du Vertrauen auf und verankerst vorhersagbarkeit mit cycle time und lead time in agilen teams als Betriebsstandard.

Mit diesem Fahrplan vermeidest du Metriken-Theater, sicherst Datenqualität und verknüpfst Charts mit Entscheidungen. Du etablierst einen Regelkreis aus Messen, Steuern, Liefern und Lernen. Vorhersagen werden dadurch Teil der täglichen Arbeit und nicht Gegenstand von Folien.

Abschliessende Gedanken

Wenn du Vorhersagbarkeit willst, musst du Zeit messen und Fluss steuern. Velocity liefert dir beides nicht. Mit klar definierten Messgrenzen für Lead Time und Cycle Time, konsequenter Datenerfassung und wenigen, präzisen Charts machst du Wartezeiten sichtbar und Engpässe adressierbar. Perzentile ersetzen Wunschdenken, Service Level Expectations ersetzen vage Zusagen. Monte-Carlo-Simulationen übersetzen vergangenes Lieferverhalten in belastbare Bandbreiten für Termine und Umfänge. WIP-Limiten, Pull, Review-SLAs und Swarming verankern tägliche Steuerung. Backtesting schützt vor Selbsttäuschung, Governance verhindert Metriken-Theater. Starte mit einem sechs­wöchigen Pilot, halte die Policies hart, kalibriere SLEs monatlich und skaliere Definitionen über Streams, nicht Präsentationen. So entsteht vorhersagbarkeit mit cycle time und lead time in agilen teams: transparent, reproduzierbar, erklärbar. Stakeholder erhalten Antworten in Kalendertagen, Teams erhalten Handlungsregeln, die wirken.