Velocity ist tot
Warum Flow Metrics die einzig wahre Messgrösse für agile Teams sind
Velocity wirkt sauber. Eine Zahl pro Sprint, die Tempo suggeriert und Planung verspricht. In der Praxis misst sie selten Leistung, sondern das Ergebnis eines Schätzrituals. Story Points sind Relationen, keine physische Einheit. Jedes Team kalibriert sie anders, jede Produktphase verschiebt die Skala. Sobald Velocity zur Zielgrösse wird, kippt sie von der Messung zur Steuerung – mit erwartbaren Nebenwirkungen.
Du kennst die Muster: Teams zerlegen Arbeit künstlich, um „mehr Punkte“ zu liefern. Refinements verlagern Energie von Klarheit und Risikoabbau hin zu Punktelogik. Eine 8 wird zur 5, weil der Sprintplan sonst nicht aufgeht. Aus „Schätzung“ wird „Commitment“. Der Diskurs verschiebt sich vom Wert zum Volumen. Diese Dynamik ist kein moralisches Problem, sondern systemisches Verhalten: Wenn eine Kennzahl bewertet wird, optimiert das System auf die Kennzahl.
Vergleichbarkeit existiert nicht. Team A liefert 42 Punkte, Team B 28. Ohne gemeinsame Skala und stabile Referenz bedeuten die Zahlen nichts. Sie werden trotzdem verglichen – und erzeugen Druck. Dieser Druck produziert Punkte-Inflation: Die Schwelle für eine „5“ sinkt, damit die Kurve steigt. Der Output wächst numerisch, der Durchsatz im Kalender nicht. Gleichzeitig verschwinden laufende, aber nicht abgeschlossene Items am Sprintende aus der Sicht. Halbfertige Arbeit bleibt unsichtbar, die tatsächliche Durchlaufzeit steigt, ohne dass Velocity dies abbildet.
Velocity ist blind für Wartezeiten. Blockierte Tickets, Abhängigkeiten, Entscheidungsverzug – all das frisst Kalenderzeit, taucht aber erst dann in der Zahl auf, wenn das Item tatsächlich „Done“ ist. Rework wird häufig in neue Tickets ausgelagert und erscheint als frischer Output, statt als Symptom von Qualitätsproblemen. So entsteht die Illusion von Tempo bei sinkender Vorhersagbarkeit. Du bekommst Präzision ohne Treffgenauigkeit: zwei Nachkommastellen im Sprintplan, aber schwankende Liefertermine.
Ein Beispiel zeigt das Dilemma. Zwei Teams liefern je zehn Stories pro zwei Wochen. Team 1 bewertet grosszügig: durchschnittlich 5 Punkte pro Story, Velocity 50. Team 2 bewertet konservativ: 3 Punkte pro Story, Velocity 30. Beide bewegen denselben Stückfluss. Das Management honoriert jedoch die 50. Das falsche Signal setzt sich fest: mehr Punkte gelten als mehr Leistung. Konsequenz: Story-Splitting nach Punktelogik, Mikroschritte im Workflow, mehr Übergaben, mehr Kontextwechsel. Die Kalenderzeit steigt, der Fluss stockt.
Schätzrunden sind teuer. Sie beanspruchen erfahrene Leute, ohne die Streuung realer Durchlaufzeiten zu reduzieren. Eine 5 bleibt eine 5, auch wenn das Team am Folgetag einen ungeplanten Architekturentscheid braucht. Die Unsicherheit verschwindet nicht, sie wird dekoriert. Planung auf Punktbasis vermittelt Kontrolle, ersetzt aber keine Evidenz. Der entscheidende Bias: Menschen überschätzen ihre Kontrolle über Variabilität und unterschätzen Wartezeiten. Velocity verstärkt diesen Bias, weil sie vergangene Schätzentscheidungen mit zukünftigen Lieferterminen verknüpft.
Stakeholder erleben dann ein zweites Problem: Verhandelte Sprintinhalte werden als Zusagen gelesen. Verschiebt sich ein Blocker, kippt die Liefererwartung – unabhängig davon, wie gut das Team gearbeitet hat. So entsteht das vielzitierte „Management-Theater“: Charts sehen gut aus, Reviews klingen gut, reale Termine bleiben dennoch unsicher. Das führt zu Eskalationsschleifen, Sonderprioritäten, „Expedite“-Pfaden. Der Fluss bricht weiter.
Hier setzt Flow Metrics statt Velocity: Prognosen ohne Schätzen an. Statt Punkte zu optimieren, optimierst Du das System, in dem Arbeit fliesst. Der Fokus wandert von der Bewertungslogik zur Zeitlogik: Wie lange dauert Arbeit tatsächlich durch Dein System? Wie viel Arbeit befindet sich gleichzeitig im System? Wie viele Einheiten beendest Du in einem realen Zeitfenster? Wie alt sind die laufenden Tickets? Diese Fragen beleuchten Engpässe, Wartezeiten und Streuung – also genau die Grössen, die Vorhersagbarkeit treiben.
Weshalb ist das wichtig? Weil Kalenderzeit die Kundenerfahrung bestimmt. Niemand bekommt Punkte geliefert. Kundinnen und Stakeholder erleben Durchlaufzeit und Liefertreue. Velocity abstrahiert das Reale weg und ersetzt es durch eine teaminterne Währung. Flow Metrics statt Velocity: Prognosen ohne Schätzen bedeutet, diese Währung wieder in reale Zeit, reale Warteschlangen und reale Entscheidungen zurückzutauschen.
Für Dich als Führungskraft oder Product Owner heisst das: Du verschiebst die Gespräche. Weg von „Wie viele Punkte schaffen wir?“ hin zu „Welche Wartezeit frisst unsere Durchlaufzeit?“ und „Welcher Engpass limitiert unseren Durchsatz?“. Du unterscheidest Ursache von Symptom. Punkteknappheit ist ein Symptom. Zu viel parallele Arbeit, unklare Policies, fehlende Verfügbarkeit von Reviewern, späte Entscheidungen – das sind Ursachen. Wenn Du Ursachen bearbeitest, verbessert sich der Fluss. Wenn Du Symptome bewertest, verbessert sich die Zahl.
Am Ende zählt Verlässlichkeit. Verlässlichkeit entsteht, wenn Streuung sinkt und Blocker schneller fallen. Das gelingt nicht durch mehr Schätzung, sondern durch weniger WIP, klarere Pull-Regeln, schnellere Entscheide und sichtbar gemachtes Altern laufender Items.
Die vier Flow Metrics: Definition und Aussagekraft
Flow beginnt, sobald du Zeit statt Punkte misst. Flow Metrics statt Velocity: Prognosen ohne Schätzen heisst, Arbeit als Warteschlange zu betrachten: Wie lange durchläuft ein Ticket das System, wie viel Arbeit steckt gleichzeitig drin, wie viel verlässt das System pro Zeitfenster, und wie alt sind die laufenden Tickets? Vier Kennzahlen genügen: Cycle Time, WIP, Throughput und Work Item Age. Sie sind einfach, robust und zueinander konsistent.
Cycle Time (Durchlaufzeit) misst Kalenderzeit von „Start der aktiven Bearbeitung“ bis „Done – nutzbar“. Definiere Start und Ende präzise, sonst zerfällt die Aussagekraft. Miss in Kalendertagen, nicht in Personenstunden, denn Blockaden, Wartezeiten und Entscheidungen bestimmen die Realität. Interpretiere die Verteilung über Perzentile statt Mittelwert: Das P50 zeigt den typischen Fall, P85 und P95 quantifizieren Vorhersehbarkeit. Ein Cycle-Time-Scatterplot macht Streuung, Ausreisser und Trends sichtbar; Perzentillinien liefern eine Service Level Expectation (SLE), etwa: „85 % aller Tickets sind in ≤ 9 Tagen fertig.“ Für Zusagen nutzt du Perzentile, nicht Hoffnungen.
WIP (Work in Progress) ist die Anzahl gleichzeitig bearbeiteter Items. Hoher WIP bedeutet Warteschlangen, Kontextwechsel und längere Cycle Time. Niedriger WIP fördert Fertigstellung statt Anfangen. WIP ist ein Steuergriff, kein Beobachtungswert: Du legst WIP-Limits pro Spalte oder Team fest und zwingst Fokus. Das macht Blocker sichtbar, weil niemand „drüber hinweg“ arbeiten kann. Ohne Limit wächst WIP still, bis Durchlaufzeiten explodieren.
Throughput (Durchsatz) zählt fertiggestellte Items pro Zeitfenster, meist pro Woche. Er ist keine Velocity in anderer Verpackung, sondern ein Ausfluss realer Fertigstellungen. Betrachte Verteilungen statt Durchschnittswerte: Wochen mit 3, 7, 0 und 5 Items erzählen mehr über Risiko als ein „Durchschnitt 3,75“. Ein Throughput-Histogramm bildet die Grundlage für Monte-Carlo-Simulationen und liefert Bandbreiten für Portfolio-Fragen („Wie viele Tickets schaffen wir bis Datum X?“).
Work Item Age (Alter laufender Arbeit) ist die vernachlässigte Frühwarnkennzahl. Sie misst, wie lange ein begonnenes Item schon im System steckt. Age ist ein Leading Indicator: Steigt das Alter eines Tickets über das Cycle-Time-P85, droht ein Überzieher. Ein Aging-WIP-Chart zeigt alle laufenden Tickets im Vergleich zu den Cycle-Time-Perzentilen. Daraus entsteht eine einfache Daily-Routine: „Wir bearbeiten zuerst das älteste Item oberhalb P85, klären Blocker und ziehen erst dann Neues.“
Die vier Kennzahlen hängen kausal zusammen. Little’s Law verbindet sie zu einer einfachen Gleichung:
WIP = Throughput × Cycle Time.
Gilt näherungsweise für stabile Systeme mit konstantem Zufluss und klaren Start/End-Definitionen. Praktische Konsequenz: Du verkürzt Durchlaufzeit am schnellsten, indem du WIP senkst (gleicher Durchsatz, kürzere Warteschlange) oder Engpässe entlastest (höherer Durchsatz bei stabilem WIP). Wer Cycle Time „verbessern“ will, ohne WIP und Engpässe anzufassen, betreibt Kosmetik.
Visualisierung schafft Einsicht über Worte hinaus. Das Cumulative Flow Diagram (CFD) zeigt Mengen über die Zeit: parallele Flächen bedeuten Stabilität, aufklaffende Schichten entlarven Engpässe. Steilere Done-Linie heisst mehr Durchsatz, breitere In-Progress-Schicht heisst höherer WIP. Kombiniert mit Scatter und Aging erkennst du drei typische Muster: zu viel parallele Arbeit (In-Progress bläht auf), wechselnde Engpässe zwischen Review/Test/Deploy (Zähne im CFD), und unterschätzte Wartezeit vor Entscheidungen (lange horizontale Bänder im Scatter).
Die Kennzahlen funktionieren nur mit sauberen Policies. Lege fest: ab wann gilt „Start“, was zählt als „Blocked“, wann ist „Done – nutzbar“. Führe Serviceklassen ein (z. B. „Fixed Date“, „Standard“, „Expedite“) und messe ihre eigenen Cycle-Time-Verteilungen. Vermische nicht „Entdecker-Tasks“ mit „Routine-Tickets“, wenn du Prognosen brauchst; bilde stattdessen Kohorten mit ähnlicher Streuung. Trenne Rework sichtbar, statt es in neue „Erfolge“ umzuwandeln.
Vermeide die drei häufigsten Fallstricke. Erstens: künstliches Slicing nach Workflow-Schritten, das scheinbar Throughput erhöht, aber Übergaben und Wartezeiten multipliziert. Zweitens: unscharfe Start/End-Definitionen, die Cycle Time unbrauchbar machen und Little’s Law unterlaufen. Drittens: vernachlässigte Blockerzeiten. Miss Blocker explizit und reduziere sie systematisch (Entscheidungs-SLAs, klare Reviewer-Verfügbarkeit, Automatisierung vor Übergaben).
Operativ genügen wenige Routinen. Im Daily prüfst du das Aging-WIP-Chart, senkst WIP, entfernst Blocker. In der Weekly analysierst du Throughput-Histogramm und Scatter, justierst Limits und Kapazitätszuschnitt. In Reviews berichtest du SLE-Treffsicherheit und Blockertrends statt Punkte. So entsteht Verlässlichkeit, messbar an sinkender Streuung und stabilen SLEs. Genau das ist der Kern von Flow Metrics statt Velocity: Prognosen ohne Schätzen.
Datenhygiene und Messmethodik
Flow Metrics wirken nur, wenn die Daten sauber sind. Flow Metrics statt Velocity: Prognosen ohne Schätzen verlangt präzise Definitionen, stabile Workflows und konsistente Messpunkte. Erst wenn Start, Ende, Blocker und Statuswechsel klar erfasst sind, spiegeln Cycle Time, WIP, Throughput und Work Item Age die reale Systemleistung.
Beginne mit eindeutigen Start- und Enddefinitionen. „Start“ ist der Zeitpunkt, an dem aktive Bearbeitung beginnt: nicht „Ready“, nicht „To Do“, sondern die erste produktive Arbeit am Item. „Ende“ ist „Done – nutzbar“: in Produktion oder technisch gleichwertig (Feature-Flag aktiviert, Kunde kann Wert ziehen). Alles dazwischen zählt als Durchlaufzeit in Kalendertagen. Personenstunden sind untauglich, weil Wartezeiten, Entscheidungswege und Abhängigkeiten den Takt bestimmen. Definiere zusätzlich einen Blocked-Zustand als explizites Flag oder eigene Spalte. Blockerzeiten werden gesondert gemessen und nicht aus der Cycle Time entfernt; sie sind Ursache, nicht Rauschen.
Stabilisiere den Workflow. Fasse Spalten auf das Notwendige zusammen: Analyse (optional), In Progress, Review/QA, Deploy, Done. Mikroschritte erzeugen Scheinpräzision und erschweren die Auswertung. Jede Spalte braucht Pull-Policies: klare Eintrittskriterien, klare Austrittskriterien. Vermeide Statuswechsel ohne Arbeit (Hin- und Herziehen), sie verzerren Aging und Cycle Time. Wenn du den Workflow änderst, dokumentiere eine Mapping-Tabelle von alt nach neu, damit historische Reihen nicht abbrechen.
Messe Aging und Cycle Time aus denselben Zeitstempeln. Cycle Time = Ende − Start. Work Item Age = Jetzt − Start für alle laufenden Items. Vergleiche Age täglich mit den Cycle-Time-Perzentilen der letzten Stichprobe. Ein Item über P85 ist Risiko und erhält Priorität. Dieser einfache Check ersetzt lange Statusrunden: Das älteste riskante Item zuerst, Blocker lösen, erst dann Neues ziehen.
Erfasse Blocker als Ereignisse mit Start- und Endzeit. Summiere Blockerzeit pro Item und aggregiere sie pro Ursache (Warten auf Entscheidung, externe Abhängigkeit, Umgebungsfehler, Ressourcenknappheit). Ein monatlicher Bericht über Blockerzeit zeigt die wahren Engpässe. Reduziere Entscheidungslatenz durch klare Service Level: beispielsweise „Architekturentscheidungen innerhalb von 2 Arbeitstagen“. Solche Regeln senken Streuung spürbar und stabilisieren SLEs.
Baue saubere Kohorten. Mische keine qualitativ unterschiedlichen Ticketarten, wenn du Vorhersagen brauchst. Trenne mindestens nach Class of Service: „Standard“, „Fixed Date“, „Expedite“. Messe für jede Klasse eigene Cycle-Time-Verteilungen und kommuniziere eigene Service Level Expectations (z. B. „Standard: 85 % ≤ 9 Tage“, „Expedite: 85 % ≤ 2 Tage“). Trenne Discovery-Tasks von Delivery-Tickets oder dokumentiere die abweichende Streuung, sonst kippt die Prognose.
Achte auf die Stichprobengrösse. Für robuste Perzentile genügen oft 20–30 abgeschlossene Items einer homogenen Kohorte. Nutze rollende Fenster: die letzten 30 Lieferungen für SLEs, die letzten 12–16 Wochen für Throughput. Entferne keine Ausreisser. Markiere sie, analysiere Ursachen, aber behalte sie in der Verteilung. Ausreisser sind Signale für Engpässe, nicht Fehler der Statistik.
Erstelle die zentralen Visualisierungen konsistent. Das Cumulative Flow Diagram zählt pro Tag die Anzahl Tickets je Spalte; generiere den Schnitt stets zur gleichen Uhrzeit, um Messrauschen zu vermeiden. Breiter werdende „In-Progress“-Flächen zeigen WIP-Wachstum und damit künftige Cycle-Time-Probleme. Der Cycle-Time-Scatterplot zeigt für jedes Item die Dauer; ziehe Perzentillinien (P50, P85, P95), um Trends und Streuung sichtbar zu machen. Das Throughput-Histogramm verdichtet abgeschlossene Items pro Woche; diese Verteilung bildet die Basis für Monte-Carlo-Simulationen. Das Aging-WIP-Chart listet alle laufenden Tickets mit ihrem Alter und den Perzentilbändern der historischen Cycle Time; es ist das operative Steuerungsinstrument im Daily.
Halte Zähleinheiten stabil. Zähle Items, nicht Punkte. Ein „Item“ ist ein vertikal geschnittenes, kundennahes Arbeitspaket. Zähle Sub-Tasks nicht separat, wenn sie nur interne Schritte abbilden. Rework gehörte zur ursprünglichen Lieferung: Entweder bleibt es im gleichen Ticket und verlängert die Cycle Time, oder es wird als Rework-Ticket transparent gemacht und separat ausgewertet. Verstecktes Rework verfälscht Throughput und erzeugt die Illusion von Tempo.
Lege Messkonventionen fest und befolge sie. Messe in Kalendertagen. Wenn du Arbeitstage ausweisen willst, tu das zusätzlich, aber verändere die SLE-Basis nicht. Dokumentiere Zeitzonen und Stichtage (z. B. CFD-Schnitt täglich um 17:00). Versioniere deine Definitionen von Start, Ende, Blocker, Done. Diese „Mess-Governance“ verhindert, dass kleine Prozessänderungen grosse Statistikbrüche verursachen.
Sorge für Datenqualität am Ursprung. Automatisiere Statuswechsel, wo immer möglich (Merge in Main → „Ready for Deploy“; erfolgreiche Pipeline → „Deployed“). Ersetze manuelle Übergaben durch Regeln im Tooling. Vermeide Sammelaktionen am Sprintende („Aufräum-Tag“), sie verzerren Throughput und verschmieren die Streuung. Prüfe wöchentlich eine Stichprobe: stimmt Start/Ende, stimmen Blockerintervalle, wurden Tickets ohne Arbeit bewegt?
Verknüpfe Messung und WIP-Steuerung. Ohne WIP-Limits bleibt Little’s Law Theorie. Setze Limits pro Spalte und Team und halte sie ein. Wenn ein Limit gerissen wird, stoppst du das Anziehen neuer Arbeit, analysierst Blocker und entlastest den Engpass. Jede Limitverletzung ist ein Lernanlass, nicht ein Anlass, das Limit zu erhöhen.Prognosen statt Schätzen: Monte-Carlo und SLE
Vorhersagen gelingen, wenn du reale Zeitverteilungen nutzt. Flow Metrics statt Velocity: Prognosen ohne Schätzen bedeutet, dass du nicht mehr fragst, wie gross ein Item ist, sondern wie lange vergleichbare Items durch dein System brauchen und wie viele pro Zeitfenster fertig werden. Zwei Monte-Carlo-Verfahren genügen: cycle-time-basiert für Einzelitems und throughput-basiert für Mengen. Beide liefern Wahrscheinlichkeiten statt Wunschtermine und machen Streuung sichtbar.
Für Einzelitems ist die Service Level Expectation (SLE) der zentrale Satz. Du nimmst die letzten 20–30 abgeschlossenen Items einer homogenen Kohorte, misst die Cycle Time vom Start der aktiven Arbeit bis „Done – nutzbar“ und bildest Perzentile. Das P85 wird zur SLE: „85 % aller Items sind in ≤ X Kalendertagen fertig.“ Diese Aussage ist eine Wahrscheinlichkeitsaussage über dein System, keine Eigenschaft eines einzelnen Tickets. Sie funktioniert nur, wenn Start und Ende sauber definiert sind und WIP-Limits gelten. Für ein bereits begonnenes Item bestimmst du die Fertigstellwahrscheinlichkeit bis zu einem Stichtag D, indem du prüfst, welcher Anteil der historischen Cycle-Time-Stichprobe ≤ Restkalenderzeit liegt. Für ein noch nicht gestartetes Item addierst du die realistische Wartezeit bis zum Start, sofern dein WIP Limit dies erzwingt; andernfalls ist die SLE Makulatur, weil parallele Starts die Warteschlange verlängern.
Für Mengen nutzt du Throughput-Monte-Carlo. Du zählst abgeschlossene Items pro Woche (oder Sprint, wenn der Sprint ein fixes Kalenderintervall abbildet) und erhältst eine Stichprobe wöchentlicher Durchsätze. Statt einen Durchschnitt zu nehmen, ziehst du in vielen Versuchen (zum Beispiel 10 000) zufällig Werte aus dieser Verteilung. Für die Frage „Wie viele Items liefern wir bis Datum X?“ simulierst du Woche für Woche bis zum Stichtag und summierst die gezogenen Throughput-Werte. Aus 10 000 Summen erhältst du ein Verteilungsspektrum: P50, P85, P95. Umgekehrt beantwortest du „Bis wann liefern wir m Items?“ indem du solange Wochen ziehst und kumulierst, bis die Summe ≥ m ist. Die resultierende Wochenanzahl wandelst du in ein Datum um und lieferst eine Wahrscheinlichkeitsaussage, zum Beispiel: „25 Items: P50 in 7 Wochen, P85 in 9 Wochen, P95 in 11 Wochen.“
Beide Verfahren sind nicht-parametrisch. Du modellierst keine Glockenkurven, sondern verwendest die echte Streuung deines Systems. Ausreisser bleiben in der Stichprobe, weil sie Ursachen signalisieren: Entscheidungsverzug, Engpass im Review, Infrastrukturfehler. Entfernst du sie, polierst du die Zukunft. Verlässlichkeit steigt, wenn Streuung sinkt; Streuung sinkt, wenn WIP-Limits greifen, Blockerzeiten schrumpfen und Engpässe entlastet werden. Prognose und Verbesserung sind damit zwei Seiten derselben Methode.
Die praktische Durchführung ist schlicht. Für SLE exportierst du pro Item Zeitstempel „Start“ und „Done“, subtrahierst und erhältst Kalendertage. Ein Scatterplot zeigt die Streuung, die Perzentillinien liefern SLE-Kandidaten. Nimm P85 als Standard-SLE, P95 als „sicher“ für riskante Stakeholder, und kommuniziere beides. Prüfe Kohorten: Standard vs. Fixed-Date vs. Expedite. Jede Klasse hat eine eigene Verteilung und damit eigene SLEs. Für Throughput-Monte-Carlo exportierst du die Liste der in jeder Woche abgeschlossenen Items. Ein Histogramm zeigt die Form; die Simulation zieht zufällig aus dieser Liste mit Zurücklegen, sodass saisonale Wochen mit 0 oder 8 Abschlüssen proportional vertreten sind.
Wichtig sind Grenzen und Annahmen. Beide Verfahren setzen stationäre Bedingungen voraus: derselbe Workflow, ähnliche Arbeit, konstante Policies, keine harte Systemänderung. Erkennst du einen Strukturbruch – deutlich geänderte WIP-Höhe im CFD, Sprung in der Median-Cycle-Time, neue Deployment-Gateways –, dann beginnst du die Stichprobe neu oder nutzt nur die letzten n Wochen/Items mit der neuen Praxis. Für kleine Samples (< 20 Items) arbeitest du mit breiteren Konfidenzen oder ergänzt die Stichprobe, bevor du Zusagen publizierst. Für saisonale Effekte (Ferien, Release-Freeze) simulierst du Szenarien: entweder du entfernst die betroffenen Wochen aus der Ziehung oder modellierst sie als Wochen mit bekanntem niedrigen Throughput.
Die Kommunikation entscheidet über Akzeptanz. Du präsentierst Wahrscheinlichkeiten als Bandbreiten, nicht als Spannen ohne Gehalt. Sage: „P85 bis 14. Februar“ statt „zwischen Januar und März“. Erkläre, dass P85 bedeutet: In 85 von 100 vergleichbaren Fällen habt ihr bis zu diesem Datum geliefert. Verknüpfe Prognosen mit Hebeln: „Wenn wir WIP in Review von 8 auf 4 senken, steigt unser wöchentlicher Median-Throughput von 4 auf 5; im Monte-Carlo rutscht das P85-Datum um eine Woche nach vorn.“ So werden Massnahmen messbar. Stakeholder sehen Ursache und Wirkung, nicht nur ein neues Datum.
Work Item Age wird zum operativen Radar, der Prognosen schützt. Wenn ein laufendes Ticket sein P85-Band überschreitet, sinkt die Treffwahrscheinlichkeit deiner SLEs. Du greifst früh ein: Blocker klären, Reviewer priorisieren, Paaren oder Mobbing einsetzen, fachlichen Engpass entlasten. Ohne Age-Disziplin frisst sich „Überalterung“ in die Stichprobe und verschiebt jedes Perzentil nach rechts. Monte-Carlo bildet diesen Drift ab; deine nächsten Prognosen werden schlechter. Deshalb gehört das Aging-WIP-Chart ins Daily, nicht ins Monatsreporting.
Expedite braucht Ehrlichkeit. Ein Expedite-Ticket verdrängt reguläre Arbeit und reduziert deren Throughput. Modellierst du Expedites nicht separat, überschätzt du die Lieferfähigkeit für Standard-Tickets. Führe eine eigene Expedite-Kohorte mit eigener SLE und simuliere ihren Effekt auf den Standard-Throughput. So zeigst du transparent: „Zwei Expedites pro Monat verlängern die P85-Fertigstellung für 25 Standard-Items um eine Woche.“ Entscheidungen über Notfälle werden damit wirtschaftlich, nicht laut.
Monte-Carlo ist kein Selbstzweck. Du nutzt es, um Entscheidungen zu verbessern: Reihenfolge, WIP-Limits, Staffing am Engpass, Architektur-Investitionen. Für Portfolios beantwortest du drei Fragen: Wie viele Items bis Datum X? Bis wann m Items? Welche Kombination aus Vorhaben passt in das verfügbare Zeitfenster mit P85-Treffsicherheit? Für Roadmaps kombinierst du Throughput-Simulation mit Serviceklassen und erhältst eine lieferbare Reihenfolge statt einer Wunschsammlung. Für einzelne Zusagen nutzt du SLE und begrenzt Risiko, indem du Commitments auf P85 triffst und P95 als Puffer kommunizierst.
Ein konkretes Beispiel macht es greifbar. Angenommen, deine Standard-Kohorte (letzte 30 Items) hat P50 = 6 Tage, P85 = 9 Tage, P95 = 13 Tage. Deine SLE lautet: „85 % in ≤ 9 Tagen.“ Ein Stakeholder fragt nach einem Ticket, das heute startet. Du sagst: „P85 bis 9 Kalendertage ab heute, P95 bis 13.“ Parallel planst du ein Epic mit 25 Items. Dein Throughput-Histogramm der letzten 16 Wochen zeigt Werte zwischen 2 und 7, Median 4. Die Monte-Carlo-Simulation liefert: 25 Items P50 in 7 Wochen, P85 in 9 Wochen, P95 in 11. Du veröffentlichst P85 als Plan und führst WIP-Disziplin ein. In Woche 3 reisst Review das WIP-Limit; Aging signalisiert Risiko. Ihr entlastet Review, der Throughput stabilisiert sich, das nächste Monte-Carlo zieht die P85-Kurve sichtbar nach vorne. Transparenz ersetzt Bauchgefühl.
Szenarien erhöhen die Aussagekraft. Du simulierst „wie heute“, „mit WIP-Limit 4 statt 6 in In-Progress“, „mit einem zusätzlichen Reviewer dienstags und donnerstags“. Jede Variante zieht aus einer modifizierten Throughput-Verteilung oder nutzt hypothetische Cycle-Time-Effekte aus bekannten Verbesserungen (z. B. verkürzte Entscheidungslatenz durch verbindliche Architektur-SLAs). Du präsentierst die Differenz in Wochen auf P85-Ebene. Führung erhält damit eine quantitative Begründung für Investitionen.
Zum Schluss ein Punkt zur Governance: SLE ist kein SLA. Ein SLA ist ein Vertragsversprechen mit Pönalen. Eine SLE ist eine empirische Erwartung, die du regelmässig mit realen Lieferungen abgleichst. Du berichtest monatlich die SLE-Treffsicherheit und die Hauptursachen verfehlter Items (Blockerzeit, Engpassüberlast, Policy-Bruch). Wenn die Treffsicherheit sinkt, änderst du nicht die Zahl, sondern das System: WIP, Policies, Verfügbarkeit am Engpass. So bleibt die SLE glaubwürdig.
Damit steht das Fundament. Du hast eine Methode, die auf deinen Daten basiert, Streuung ernst nimmt und Entscheidungen unterstützt. In Kapitel 5 geht es um den Hebel, der jede Prognose schlägt: den Fluss selbst. Du optimierst Engpässe, senkst WIP, reduzierst Blockerzeit – und siehst die Wirkung unmittelbar in SLE und Monte-Carlo. Genau das ist der Kern von Flow Metrics statt Velocity: Prognosen ohne Schätzen.
Für Multi-Team-Flows gilt: Richte eine gemeinsame Definition von Start/Ende am Wertstrom aus, nicht an Teamgrenzen. Messe Cycle Time über Teamhandovers hinweg. Stimme Serviceklassen ab und harmonisiere WIP-Limits an Schnittstellen. Andernfalls verschiebst du Wartezeit von Team zu Team, ohne die Durchlaufzeit zu senken.
Am Ende entscheidet die Betriebsroutine. Im Daily priorisiert ihr mit dem Aging-WIP-Chart, löst Blocker, senkt WIP. Wöchentlich analysiert ihr Scatter und Throughput-Histogramm, passt Limits, Kapazität und Policies an. Monatlich berichtet ihr SLE-Treffsicherheit, Blockerzeit nach Ursache und die Breite der „In-Progress“-Schicht im CFD.
Flow verbessern: Vom „schneller arbeiten“ zum „besser fliessen“
Leistung entsteht, wenn Arbeit das System zügig und vorhersagbar durchläuft. Flow Metrics statt Velocity: Prognosen ohne Schätzen richtet den Fokus auf Wartezeiten, Engpässe und Streuung. Du verbesserst nicht die „Arbeitsgeschwindigkeit“ einzelner Personen, sondern die Durchflussfähigkeit des Systems. Drei Hebel dominieren: weniger parallele Arbeit, kürzere Entscheidungswege, glattere Handovers.
Beginne mit WIP-Disziplin. Lege pro Spalte verbindliche WIP-Limits fest und halte sie ein. Wenn das Limit erreicht ist, ziehst du kein neues Ticket. Du schliesst laufende Arbeit ab oder entfernst Blocker. So verkürzt du Warteschlangen und senkst die Cycle Time ohne Mehrleistung. Im Aging-WIP-Chart priorisierst du strikt nach Alter: das älteste Item über P85 zuerst. Diese Reihenfolge stabilisiert SLEs und zwingt Engpassarbeit ins Zentrum. Jede Limitverletzung wird ausgewertet: Warum entstand sie? Was änderst du an Policies, Kapazität oder Schnittstellen?
Entlaste den Engpass, nicht die Auslastung. Identifiziere per CFD und Scatter, wo Arbeit staut: häufig Review/QA oder Entscheidungspunkte. Richte fixe Verfügbarkeitsfenster ein (z. B. Review jeden Vormittag, Architekturentscheid innerhalb von 2 Arbeitstagen). Miss Blockerzeit nach Ursache und reduziere sie gezielt: dedizierte Reviewer, verbindliche Entscheidungs-SLAs, klare Eskalationspfade. Erhöhe Skill-Fluidität durch Pairing, Mobbing und kurze Wissensmodule; das glättet Zufluss zum Engpass. Das Ziel ist nicht Auslastung = 100 %, sondern Puffer am Engpass, damit Warteschlangen gar nicht erst wachsen.
Reduziere Batchgrössen. Vertikal geschnittene, kundennahe Items fliesen schneller als Funktionssplitter. Schneide so, dass ein Item ohne zusätzliche Handovers fertigstellbar bleibt. Vermeide interne Sub-Tasks als eigenstaendige Tickets; sie erhöhen Übergaben, senken Flow Efficiency und blähen WIP. Korrigiere Slicing-Regeln in der Retrospektive: Welche Item-Sorten überschreiten regelmässig P85? Welche Definition-of-Ready-Kriterien verhindern Rework?
Automatisiere Handovers und Deploymentpfade. Jeder manuelle Übergang verlängert Wartezeit. Integriere CI/CD mit klaren Statuswechseln: Merge → automatisches Build/Test → „Ready for Deploy“. Führe trunkbasiertes Arbeiten und Feature-Flags ein, damit „Done – nutzbar“ nicht an seltene Release-Fenster gebunden ist. Jede verkürzte Handover-Latenz reduziert Streuung direkt; das siehst du als engeres Band im Scatter und kleinere Perzentilabstände.
Steuere Klassen von Arbeit explizit. „Standard“, „Fixed Date“, „Expedite“ erhalten eigene Policies, eigene SLEs und eigene Visualisierung. Expedites verdrängen Standardarbeit messbar. Limitiere Expedites hart (z. B. maximal 1 gleichzeitig) und simuliere ihren Throughput-Verlust offen. Fixed-Date-Items erhalten Vorlaufpuffer: Ziehe sie so früh, dass ihr P85 vor dem Kalendardatum liegt. Diese Klarheit verhindert verdeckte Prioritätskämpfe und stabilisiert den Fluss der Standardkohorte.
Optimiere Flow Efficiency systematisch. Messe aktive Zeit vs. Gesamtdauer pro Item. Hohe Warteanteile deuten auf Koordinations- oder Entscheidungsstaus. Greife dort an: gemeinsame „Review-Windows“, verbindliche Antwortzeiten, geringere „WIP vor Review“, klare Ownership für Umgebungsstörungen. Senke Kontextwechsel durch Fokusslots und sichtbare „Do-Not-Disturb“-Zeiten für Engpassrollen. Jede Stunde weniger Wartezeit verbessert SLEs ohne Mehraufwand.
Etabliere operative Routinen statt Einmalaktionen. Im Daily prüft ihr zuerst das Aging-WIP-Chart, dann Blocker, dann WIP-Limits. Im Weekly analysiert ihr Throughput-Histogramm und Scatter, passt Limits und Kapazitätszuschnitt an und überprüft die Treffgenauigkeit der SLEs. Monatlich berichtet ihr Blockerzeit nach Ursache, Rework-Quote, Handovers pro Item und die Breite der In-Progress-Schicht im CFD. Diese vier Kennzahlen erzählen, ob Verbesserungen wirken: sinkende Blockerzeit, fallende Rework-Quote, weniger Handovers, schmalere In-Progress-Fläche.
Arbeite mit klaren Policies. Definiere Eintritts- und Austrittskriterien pro Spalte, mache „Blocked“ sichtbar, untersage Rückwärtsbewegungen ohne Grund. Lege „Pull vor Push“ fest: Niemand „gibt weiter“, Teams „ziehen“. Lege „Aging-Alerts“ fest: Ab P85 löst die Spalte Massnahmen aus (Pairing, Reviewer-Priorisierung, Eskalation). Policies sind öffentlich und kurz; sie ersetzen stillschweigende Erwartungen durch überprüfbare Regeln.
Verankere Transparenz gegenüber Stakeholdern. Reporte SLE und Throughput-Bänder statt Story Points. Zeige, wie WIP-Disziplin und Engpassentlastung Termine verschieben. Visualisiere den Effekt von Entscheidungen mit Szenarien: „Review-WIP 4 statt 8“ oder „zweites Review-Fenster pro Woche“ und die resultierende P85-Verschiebung im Monte-Carlo. So verknüpfst du Investitionen direkt mit Lieferfähigkeit.
Vermeide drei Antimuster. Erstens: „Mehr Leute am Nicht-Engpass“. Das steigert WIP und verschärft Wartezeiten. Zweitens: „Limit hochsetzen, weil es eng wird“. Das löscht Alarmsignale und verlängert die Queue. Drittens: „Rework in neue Tickets auslagern“. Das poliert Throughput, verschleiert Qualitätskosten und zerstört SLE-Treffer.
Skaliere über Teamgrenzen entlang des Wertstroms. Messt Cycle Time über Übergaben hinweg und harmonisiert Serviceklassen. Legt WIP-Limits an Schnittstellen fest (z. B. „max. 5 Items warten auf Security-Review“) und belegt Schnittstellen mit klaren Antwortfenstern. Ohne diese Klammer verschiebst du Wartezeit lediglich zwischen Teams.
Das Ergebnis spürst du in den Daten: schmalere In-Progress-Fläche im CFD, engere Perzentilbänder im Scatter, stabilere Weekly-Throughputs, weniger Items über P85 im Aging. Genau diese Signaturen sind das Zielbild von Flow Metrics statt Velocity: Prognosen ohne Schätzen. Wenn sie sichtbar werden, steigen Verlässlichkeit und Liefertreue – ohne Überstunden, ohne Punktespiele, mit einem System, das Arbeit fliessen lässt.
Kultur und Steuerung: Weg von Punkten, hin zu Verlässlichkeit
Verlässlichkeit entsteht aus klaren Regeln, sichtbaren Daten und konsequenten Entscheidungen. Punkte und Velocity verschwinden aus der Steuerung. Flow Metrics statt Velocity: Prognosen ohne Schätzen wird zur Leitidee: Du steuerst über Durchlaufzeit, WIP, Throughput und Work Item Age und misst die Treffgenauigkeit der SLEs. Führung schafft die Rahmenbedingungen, in denen Flow priorisiert wird – nicht Auslastung, nicht Punktesummen.
Beginne mit einem Flow-Charter. Definiere Start und Ende, Blocker, Serviceklassen, WIP-Limits und die SLE-Regel (Standard P85, riskant P95). Lege fest, dass Teams nicht über Velocity verglichen werden. Commitments erfolgen auf Basis der SLE und der throughput-basierten Monte-Carlo-Prognosen. Miss jeden Monat die SLE-Treffsicherheit je Serviceklasse und die Blockerzeit nach Ursache. Aus diesen Zahlen leitest du Entscheidungen ab: Limits anpassen, Verfügbarkeit am Engpass erhöhen, Entscheidungs-SLAs schärfen.
Richte operative Kadenzen am Flow aus. Im Daily führst du mit dem Aging-WIP-Chart: ältestes Item über P85 zuerst, Blocker lösen, erst dann Neues ziehen. Im Weekly prüfst du Scatter und Throughput-Verteilung, passt WIP-Limits und Kapazitätszuschnitt am Engpass an und validierst die SLE-Bänder. Im Monthly berichtest du SLE-Treffsicherheit, Blockertrend, Rework-Quote und die Breite der In-Progress-Schicht im CFD. Diese vier Kennzahlen bilden das Steuerungs-Cockpit. Jede Abweichung triggert Massnahmen, nicht Erklärungen.
Ändere Anreize. Boni und Zielvereinbarungen koppeln an Verlässlichkeit, nicht an Menge. Geeignet sind: SLE-Treffsicherheit pro Serviceklasse, Reduktion durchschnittlicher Blockerzeit, Einhaltung von WIP-Limits, sinkende Streuung in der Cycle Time. Ungeeignet sind: Punkte pro Sprint, Story-Count, subjektive „Auslastung“. Goodhart’s Law wird so entschärft: Du belohnst Systemverbesserung statt Zahlenspiele.
Stärke Entscheidungsfähigkeit am Engpass. Lege verbindliche Entscheidungs-SLAs fest (z. B. Architekturentscheide in zwei Arbeitstagen, Review-Fenster täglich 09:00–11:00). Plane explizit Puffer am Engpass, damit Warteschlangen gar nicht erst wachsen. Rotationen, Pairing/Mobbing und kurze Lernmodule erhöhen Skill-Fluidität und verhindern, dass einzelne Personen zu Ein-Personen-Queues werden. In der Steuerung zählt die verfügbare Engpass-Kapazität mehr als die nominelle Teamgrösse.
Behandle Expedites ehrlich. Begrenze sie hart (maximal eins gleichzeitig), führe eine eigene SLE und simuliere ihren Effekt auf den Standard-Throughput. Jede Expedite-Entscheidung ist wirtschaftlich zu begründen: Sie kostet Prognosequalität und verschiebt P85-Daten. Diese Transparenz reduziert unkoordinierte „Feueralarme“ und schützt den Standardfluss.
Skaliere über Teams mit Portfolio-WIP. Limitiere parallel laufende Initiativen entlang des Wertstroms. Eine neue Initiative startet erst, wenn eine andere fertig ist oder aktiv gestoppt wird. Portfolio-Reviews nutzen throughput-basierte Monte-Carlo-Simulationen, um lieferbare Bandbreiten zu zeigen („Wie viele Features bis Datum X mit P85?“). Roadmaps werden zu Wahrscheinlichkeitskorridoren, nicht zu Wunschlisten. So entsteht eine Pipeline, die liefert, statt eine Staukette.
Verankere Governance als leichtgewichtige Regeln im Tooling. Automatisiere Statuswechsel, verankere WIP-Limits technisch, erfasse Blockerintervalle verpflichtend, zeige Aging-WIP und SLE-Bänder auf allen Boards. Ersetze Velocity-Reports durch ein einheitliches Flow-Dashboard: SLE-Treffsicherheit, Median/P85-Cycle-Time, Throughput-Histogramm, Blockerzeit nach Ursache. Dieses Dashboard ist öffentlich. Damit verschwindet Reporting-Theater, weil jeder denselben Zustand sieht.
Öffne Feedback-Schleifen zwischen Produkt und Technik. Produkt priorisiert mit Blick auf SLE-Bänder und Engpasslast, Technik verpflichtet sich auf Massnahmen, die Streuung senken: kleinere Batches, weniger Übergaben, klarere Pull-Policies. Beide Seiten verhandeln Wahrscheinlichkeiten, nicht Deutungshoheiten. Terminänderungen werden als Bandverschiebungen kommuniziert („P85 rutscht von KW 12 auf KW 13, Hauptursache: Review-Wartezeit +18 %“). So bleibt Vertrauen intakt, auch wenn Risiken eintreten.
Behandle Verbesserungen als Arbeit mit WIP. Reserviere stabil 15–20 % Kapazität für Verbesserungen, die Flow messbar beeinflussen: Entscheidungs-SLAs, Testautomatisierung, Build-Zeiten, Reviewer-Verfügbarkeit, Deploy-Frequenz. Jede Massnahme erhält eine erwartete Wirkung auf SLE oder Throughput und wird nach vier Wochen gegen die Daten geprüft. Bleibt der Effekt aus, passt du an oder beendest die Massnahme. So entsteht ein lernendes System statt einer Ideenliste.
Korrigiere Leistungsbeurteilung und Karrierepfade. Honoriert werden: WIP-Disziplin, Blockerentfernung, Engpassentlastung, Reduktion von Streuung, gelernte Fähigkeiten, die den Fluss stabilisieren. Heldentaten am Wochenende zählen nicht, wenn sie auf Prozessschulden beruhen. Wer Flow verbessert, steigert Unternehmenswert messbar. Diese Logik muss sich in Beförderungen und Gehältern spiegeln, sonst kehrt Velocity durch die Hintertür zurück.
Schliesse Antimuster aus. Keine Teamvergleiche über Velocity. Keine künstlichen Splits zur Erhöhung des Throughputs. Keine Limit-Erhöhungen als Standardreaktion. Kein Verstecken von Rework in neuen Tickets. Kein „Fertig schieben“ gegen das Aging. Jede Ausnahme hinterlässt Spuren in Scatter, CFD und SLE-Treffsicherheit – du adressierst sie systemisch, nicht rhetorisch.
So entsteht eine Kultur, die Flow als Produktivitätskern versteht. Flow Metrics statt Velocity: Prognosen ohne Schätzen ist dann keine Metrik-Sammlung, sondern ein Führungsmodell: Du triffst Entscheidungen auf Basis echter Zeit, begrenzt parallele Arbeit, schützt den Engpass, misst Lernfortschritt an sinkender Streuung und stellst Prognosequalität über Punktzahlen. Verlässlichkeit wird zur Eigenschaft des Systems, nicht zur Laune eines Sprints.
Umsetzung in 30 Tagen: Schritt-für-Schritt-Plan
Der Wechsel von Punkten zu Zeit gelingt, wenn du in kurzer Frist saubere Daten, klare Regeln und sichtbare Routinen etablierst. Flow Metrics statt Velocity: Prognosen ohne Schätzen wird in vier Wochen operativ: erst messen, dann begrenzen, danach vorhersagen, zum Schluss verankern. Jede Woche liefert konkrete Artefakte und überprüfbare Effekte in Cycle Time, WIP, Throughput und Work Item Age.
Woche 1 – Fundament und Transparenz
Definiere Start und Ende präzise („Start der aktiven Bearbeitung“ und „Done – nutzbar“). Führe „Blocked“ als expliziten Zustand mit Zeitstempeln ein. Vereinfache den Workflow auf wenige, eindeutige Spalten und dokumentiere Pull-Kriterien. Richte tägliche Exporte oder automatische Abfragen ein und erstelle vier Visualisierungen: Cumulative Flow Diagram, Cycle-Time-Scatter mit P50/P85/P95, Throughput-Histogramm pro Woche, Aging-WIP-Chart mit Perzentilbändern. Bestimme eine homogene Kohorte („Standard“) und lies die ersten Perzentile aus den letzten 20–30 Lieferungen. Ergebnis der Woche: ein belastbares Datenset, sichtbare Streuung, erste SLE-Kandidaten. Erfolgskriterium: jede Führungskraft sieht denselben Zustand, ohne Punktebericht.
Woche 2 – WIP-Disziplin und Engpassarbeit
Setze verbindliche WIP-Limits pro Spalte. Starte konservativ: In-Progress maximal Teamgrösse, Review maximal halbe Teamgrösse. Führe im Daily eine feste Reihenfolge ein: Aging zuerst, Blocker entfernen, erst dann Neues ziehen. Lege Entscheidungs-SLAs fest (Architektur, Security, Fachentscheid) und definiere feste Review-Fenster. Messe Blockerzeit nach Ursache und zeige sie wöchentlich. Entlaste gezielt den Engpass durch Pairing/Mobbing, kurze Lernmodule und planbare Reviewer-Verfügbarkeit. Ergebnis der Woche: sinkende In-Progress-Fläche im CFD, weniger Items über P85 im Aging, kürzere Warteketten im Scatter. Erfolgskriterium: keine Limit-Erhöhung als Reflex; jedes Limit-Event führt zu einer Massnahme.
Woche 3 – Prognosen und Commitments
Fixiere die Service Level Expectation für die Standard-Kohorte auf P85 und kommuniziere sie als Datumsversprechen in Kalendertagen. Trenne Class of Service: Standard, Fixed Date, Expedite; ermittle jeweils eigene Verteilungen. Starte throughput-basierte Monte-Carlo-Simulationen auf Basis der letzten 12–16 Wochen und beantworte zwei Fragen für das Portfolio: „Wie viele Items bis Datum X?“ und „Bis wann liefern wir m Items?“. Veröffentliche Bandbreiten mit P50/P85/P95, und verknüpfe sie mit Hebeln: WIP-Änderungen, zusätzliche Review-Fenster, reduzierte Blockerzeit. Ergebnis der Woche: Commitments auf P85, Szenarien mit klarer Wirkung, Roadmap als Wahrscheinlichkeitskorridor statt Wunschliste. Erfolgskriterium: Stakeholder akzeptieren Bandbreiten, weil die Herleitung sichtbar ist.
Woche 4 – Governance und Skalierung
Ersetze Velocity-Reporting durch ein Flow-Dashboard: SLE-Treffsicherheit je Klasse, Median/P85-Cycle-Time, Throughput-Histogramm, Blockerzeit nach Ursache. Verankere Regeln im Tooling: technische WIP-Limits, automatische Statuswechsel, Pflichtfelder für Blockerintervalle, prominente Aging-Ansicht auf allen Boards. Limitiere Portfolio-WIP entlang des Wertstroms und messe Cycle Time über Teamgrenzen hinweg. Lege 15–20 % stabile Kapazität für Verbesserungen fest, jede Massnahme mit erwarteter Wirkung auf SLE oder Throughput und Review nach vier Wochen. Ergebnis der Woche: ein leichter, messbasierter Steuerungsrahmen und ein Portfolio, das liefert. Erfolgskriterium: steigende SLE-Treffsicherheit, sinkende Streuung, weniger Expedites.
Tägliche und wöchentliche Routinen
Täglich priorisiert ihr mit dem Aging-WIP-Chart, löst Blocker, haltet Limits ein. Wöchentlich analysiert ihr Scatter und Throughput, prüft Limitverletzungen, passt Entscheidungs-SLAs an und schliesst mindestens ein überaltertes Item ab, bevor Neues gestartet wird. Monatlich berichtet ihr SLE-Trefferquote, Blockerzeit nach Ursache, Rework-Quote und die Breite der In-Progress-Schicht im CFD. Diese vier Kennzahlen sind das Frühwarnsystem und die Erfolgsmessung.
Messbare Zielbilder nach 30 Tagen
Die In-Progress-Fläche im CFD stabilisiert sich, P85 und P95 rücken näher an den Median, Wochen mit Null-Throughput werden seltener, Expedites laufen kontrolliert mit eigenen SLEs. Commitments basieren auf P85 und treffen häufiger. Entscheidungen werden innerhalb definierter SLAs gefällt. Stakeholder erhalten Bandbreiten, die sich gegen die Realität behaupten. Genau so wird Flow Metrics statt Velocity: Prognosen ohne Schätzen vom Konzept zur Praxis: Du steuerst reale Zeit, reduzierst Streuung und erhöhst Verlässlichkeit – sichtbar in den Daten, spürbar in der Lieferung.
Abschliessende Gedanken
Velocity war ein Hilfskonstrukt. Es versprach Vergleichbarkeit und Planung, lieferte aber Anreize für Punktespiele und Scheingenauigkeit. Der Wechsel zu Flow Metrics statt Velocity: Prognosen ohne Schätzen korrigiert diese Verzerrung. Er verankert Steuerung in Kalenderzeit, Warteschlangen und Engpässen. Du ersetzt Relationen durch beobachtbare Dauer, Punktezuwachs durch echten Durchsatz und Gefühl durch Verteilungen mit klaren Perzentilen.
Der Kern ist einfach: Begrenze parallele Arbeit, mache Blocker sichtbar, stabilisiere Entscheidungen, automatisiere Handovers. Miss Cycle Time in Kalendertagen, halte WIP-Limits ein, beobachte Throughput als Verteilung und nutze Work Item Age als Radar. Aus diesen vier Grössen entstehen SLEs und Monte-Carlo-Prognosen, die Termine als Wahrscheinlichkeiten ausdrücken. Sobald Streuung sinkt, steigt Verlässlichkeit – messbar im engeren P85-Band, sichtbar im CFD, spürbar in stabileren Lieferungen.
Führung verschiebt die Gespräche. Statt „Wie viele Punkte schaffen wir?“ fragst du „Welche Wartezeit verlängert unsere Cycle Time?“ und „Welche Entscheidung limitiert den Durchsatz?“. Governance wird leichtgewichtig und konsequent: klare Start-/End-Definitionen, Portfolio-WIP, Entscheidungs-SLAs, öffentliche Flow-Dashboards. Anreize belohnen Treffgenauigkeit, Blockerabbau und Engpassentlastung, nicht Volumen.
Der kulturelle Effekt ist nachhaltig. Teams optimieren nicht länger die Metrik, sondern den Fluss. Stakeholder erhalten Bandbreiten, die real eintreffen. Expedites werden seltene, transparent bepreiste Ausnahmen. Verbesserungen konkurrieren nicht mit Lieferung, sie sind Teil der Lieferung. Aus Planungstheater wird Betriebssicherheit.
Wenn du heute beginnst, hast du in 30 Tagen ein System, das Arbeit fliessen lässt und Termine probabilistisch absichert. Danach wächst Reife nicht über neue Rituale, sondern über geringere Streuung und schnellere Entscheidungen. Genau das zählt. Du lieferst Wert in Zeit – ohne Punkte, ohne Ratespiele, mit Daten, die halten.