Kumulatives Flussdiagramm

Ziel

Das kumulative Flussdiagramm zeichnet die Geschichte eines Arbeitsflusses auf: Es zeigt, wo sich Arbeit staut und wie lange sie für den Durchgang braucht. Ein Kanban-Board oder ein Taskboard zeigt den Stand der Arbeit an einem bestimmten Tag. Das Diagramm reiht diese Momentaufnahmen Tag für Tag aneinander: Jede Spalte wird zu einem Band, jeder Tag zu einem Punkt auf der Zeitachse.

Das Team liest daraus ab, welcher Zustand mehr Kapazität braucht, wo es eine WIP-Limite setzen oder verschärfen soll und welche Durchlaufzeit es einem Auftraggeber nennen kann. Das Ergebnis ist das laufend nachgeführte Diagramm mit einer Aufstellung der Metriken über ein Zeitfenster von einigen Wochen: mittlere laufende Arbeit, Durchsatz, Durchlaufzeit, Zykluszeit und ihre Prüfung mit Littles Gesetz.

Burndown- und Burn-up-Charts vergleichen den Fortschritt eines Sprints oder eines Releases mit einem zugesagten Umfang und einem Termin: Schafft das Team, was es zugesagt hat? Das kumulative Flussdiagramm bildet einen kontinuierlichen Fluss über ein beliebiges Zeitfenster ab, unabhängig von Sprints. Es zeigt, wo die Arbeit wartet.

Einsatz

Wann einsetzen

• Kontinuierlicher Fluss ohne feste Iteration: Applikationssupport, Änderungsanträge, Dossierbearbeitung.
• Klagen über Durchlaufzeiten ohne benannte Ursache: Das breiter werdende Band zeigt den Zustand, der die Arbeit zurückhält.
• Einstellen einer WIP-Limite: Littles Gesetz beziffert die erwartete Wirkung, das Diagramm zeigt die erreichte.
• Durchlaufzeit, die einem Auftraggeber genannt oder in ein Service Level Agreement (SLA) geschrieben wird: Die gemessene Durchlaufzeit, an einem Perzentil abgelesen, ersetzt die Schätzung.
• Scrum-Team, dessen Elemente während des Sprints stocken: Das Diagramm lässt sich auch über die Spalten des Sprint-Boards zeichnen.
• Tracking-Werkzeug, das jeden Zustandswechsel datiert: Die Historie besteht bereits, sie muss nur kumuliert werden.

Wann nicht einsetzen

• Einmalige Lieferung mit festem Termin: Die Frage lautet dann "Werden wir rechtzeitig fertig?", dafür das Burn-up-Chart nehmen.
• Weniger als etwa zehn gelieferte Elemente pro Monat: Die Kurven schrumpfen auf wenige Stufen, stattdessen das Alter jedes Elements auf dem Board verfolgen.

Beschreibung

Kurven und Bänder

Die waagrechte Achse zeigt die Zeit, in Arbeits- oder Kalendertagen. Die senkrechte Achse zeigt eine kumulierte Anzahl Elemente. Jeder Zustand hat seine Kurve: Sie zählt für jeden Tag die Elemente, die diesen Zustand erreicht haben, ob sie noch dort sind oder schon weiter. Elemente, die vor dem Zeitfenster geliefert wurden, gehen nicht in die Zählung ein. Eine kumulierte Kurve fällt deshalb nie, ausser wenn ein Element zurückgezogen oder zurückgeschickt wird.

Die Kurven stapeln sich in der Reihenfolge des Boards. Die Kurve "Erledigt" bildet den unteren Rand des Diagramms. Die vorgelagerten Zustände liegen darüber, und die oberste Kurve zählt die zugesagten Elemente. Der Raum zwischen zwei benachbarten Kurven ist das Band eines Zustands.

Drei Grenzen teilen den Fluss. Der Zusagepunkt (Commitment Point) ist der Moment, in dem sich das Team verpflichtet, ein Element zu liefern: Das Element verlässt die Liste der Anfragen und tritt in das System ein. Der Arbeitsbeginn ist der Eintritt in den ersten Zustand, in dem jemand am Element arbeitet. Die Lieferung ist der Eintritt in "Erledigt". Nicht zugesagte Anfragen bleiben ausserhalb des Diagramms. Ihre Liste wächst und schrumpft mit den Priorisierungsentscheiden, und ihr Band würde den Massstab der übrigen erdrücken.

Die Flussmetriken

Im Diagramm ist die laufende Arbeit der senkrechte Abstand zwischen der Zusagekurve und der Kurve "Erledigt". Der Durchsatz ist die Steigung der Kurve "Erledigt". Die Durchlaufzeit ist der waagrechte Abstand zwischen denselben Kurven, die Zykluszeit der waagrechte Abstand zwischen der Kurve des Arbeitsbeginns und der Kurve "Erledigt". Verlassen die Elemente das System in der Reihenfolge, in der sie eingetreten sind, ergibt der waagrechte Abstand die Durchlaufzeit des abgelesenen Elements. Sonst nähert er die mittlere Durchlaufzeit an.

Die Namen wechseln von Autor zu Autor und von Werkzeug zu Werkzeug. Manche Werkzeuge nennen das Intervall zwischen Zusage und Lieferung Zykluszeit. In der Lean-Tradition, zu der das Value Stream Mapping gehört, bezeichnet Zykluszeit die Bearbeitungszeit an einem einzelnen Prozessschritt. Andere Teams messen die Durchlaufzeit ab der Anfrage statt ab der Zusage. Das Team legt seine Grenzen auf dem Board fest und stellt seine Definition der Aufstellung voran. Eine Durchlaufzeit ohne ihre zwei Grenzen lässt sich mit keiner anderen vergleichen.

Littles Gesetz

John D. C. Little hat eine Beziehung der Warteschlangentheorie bewiesen, L = λW: Die mittlere Zahl der Elemente in einem System ist gleich ihrer mittleren Ankunftsrate multipliziert mit der mittleren Zeit, die sie darin verbringen.

Das Gesetz gilt für Mittelwerte und für ein stabiles System: Über das beobachtete Zeitfenster halten sich Ankünfte und Abgänge ungefähr die Waage, die laufende Arbeit endet auf ihrem Anfangsniveau und jedes zugesagte Element verlässt das System, geliefert oder zurückgezogen. Die Abgangsrate ersetzt dann die Ankunftsrate λ. In den Begriffen des Flusses:

Mittlere laufende Arbeit = Mittlerer Durchsatz × Mittlere Durchlaufzeit, daraus Mittlere Durchlaufzeit = Mittlere laufende Arbeit ÷ Mittlerer Durchsatz.

Das Gesetz gilt zwischen zwei beliebigen Grenzen, sofern die laufende Arbeit zwischen denselben Grenzen gezählt wird. Die Zahl der Elemente zwischen Arbeitsbeginn und Lieferung, geteilt durch den Durchsatz, ergibt die mittlere Zykluszeit. Die Zahl der Elemente, die vor dem Arbeitsbeginn warten, geteilt durch den Durchsatz, ergibt die mittlere Wartezeit. Die Durchlaufzeit zerfällt in Wartezeit plus Zykluszeit, beide im selben Diagramm abgelesen. Im Beispiel weiter unten sind in den stabilen Wochen 8 Elemente in "Umsetzung" oder "Im Review", und 4 warten in "Bereit", bei einem Durchsatz von 6 pro Woche. Die mittlere Zykluszeit beträgt 8 ÷ 6, etwa 1,3 Wochen, die Wartezeit 4 ÷ 6, etwa 0,7 Wochen: Ein Drittel der 2 Wochen Durchlaufzeit vergeht, bevor jemand das Element anfasst.

Wie Sie aus dieser Beziehung eine WIP-Limite ableiten, lesen Sie unter Kanban-Board und WIP-Limiten.

Das Diagramm aufsetzen

1. Zustände benennen und Grenzen setzen. Das Team übernimmt die Spalten seines Boards und markiert Zusagepunkt, Arbeitsbeginn und Lieferung. Jeder Zustand hat eine schriftliche Eintrittsregel, sonst ordnen zwei Personen dasselbe Element unterschiedlich ein.
2. Festlegen, was gezählt wird. Ein Diagramm zählt Elemente und übergeht ihre Grösse. Das Team fasst darin deshalb Elemente vergleichbarer Grösse zusammen. Incidents und Änderungsanträge erhalten je ein eigenes Diagramm.
3. Die Übergangsdaten erfassen. Für jedes Element hält das Tracking-Werkzeug fest, an welchem Tag es in jeden Zustand eingetreten ist. Ohne Werkzeug zählt das Team die Karten jeder Spalte täglich zur selben Uhrzeit.
4. Das Zeitfenster wählen. Es umfasst mehrere Durchlaufzeiten: Ein Mittelwert über weniger als eine Durchlaufzeit enthält nur die schnellen Elemente.
5. Zeichnen. Das Team zählt für jeden Tag und jeden Zustand die Elemente, die in diesen oder einen weiter fortgeschrittenen Zustand eingetreten sind. Es stapelt die Kurven mit "Erledigt" zuunterst und setzt die Zählung von "Erledigt" am ersten Tag des Zeitfensters auf null.
6. Ablesen und rechnen. Das Team erkennt die Muster und hält mittlere laufende Arbeit, Durchsatz, Durchlaufzeit und Zykluszeit fest. Es teilt die mittlere laufende Arbeit durch den Durchsatz und vergleicht das Ergebnis mit der mittleren Durchlaufzeit, die Element für Element gemessen wurde. Eine Abweichung weist auf einen instabilen Fluss oder auf falsche Daten hin: Elemente, die ohne Durchlaufen der Zustände geschlossen wurden, Rückschritte, die niemand erfasst hat.
7. Handeln, dann erneut ablesen. Nach einer neuen WIP-Limite verlassen die bereits zugesagten Elemente das System mit der Durchlaufzeit, die sie angesammelt haben. Die gemessene Durchlaufzeit sinkt erst nach einer Dauer, die der alten Durchlaufzeit entspricht, im Beispiel nach zwei Wochen. Das Team wartet mindestens so lange, bevor es die Massnahme beurteilt.

Die Muster lesen

Bänder gleichbleibender Dicke beschreiben einen stabilen Fluss: Jeder Zustand gibt so viel weiter, wie er erhält. Ein breiter werdendes Band beschreibt einen Zustand, der mehr erhält, als er weitergibt: den Engpass. Das Band darunter wird schmaler, weil dem nachgelagerten Zustand die Arbeit ausgeht. Die Regel gilt für einen Zustand, in dem gearbeitet wird. Bei einem Wartezustand wie einer Spalte "Bereit für Review" zeigt das breiter werdende Band den Engpass im folgenden Zustand, der keine Arbeit mehr zieht.

Eine flache Kurve "Erledigt" zeigt, dass nichts herauskommt: eine Blockade, ein Release-Freeze, Ferien. Eine treppenförmige Kurve "Erledigt" zeigt gebündelte Lieferungen, und die Durchlaufzeit jedes Elements enthält die Wartezeit auf das Bündel. Eine Zusagekurve, die schneller steigt als die Kurve "Erledigt", zeigt ein Team, das mehr zusagt, als es liefert: Laufende Arbeit und Durchlaufzeit wachsen gemeinsam. Eine fallende Kurve zeigt einen Rückzug oder einen Rückschritt, und das Team prüft seine Daten, bevor es Schlüsse zieht.

Was die Lesart verfälscht

Ein Mittelwert verbirgt das blockierte Element. Eine Karte, die seit drei Wochen stillsteht, verschiebt ein Band kaum. Das Alter jedes offenen Elements, auf dem Board verfolgt, macht sie an dem Tag sichtbar, an dem sie die übliche Durchlaufzeit überschreitet.

Nachträglich eingetragene Übergänge verschieben die Kurven. Eine Karte, die am Freitag für eine am Dienstag beendete Arbeit verschoben wird, zählt das Element drei Tage zu spät in "Erledigt". Führt das ganze Team das Board am Freitag nach, zeigt das Diagramm Bündel, die es nie gab. Die mittlere Durchlaufzeit ändert sich wenig; die Durchlaufzeit jedes einzelnen Elements ist falsch. Das Anzeichen ist eine treppenförmige Kurve "Erledigt", deren Stufen jeweils auf den Tag fallen, an dem das Team das Board nachführt, während die Releases einem anderen Rhythmus folgen.

Rückschritte verwischen die Kurven. Ein Review schickt ein Element von der Spalte "Im Review" zurück in die Spalte "Umsetzung". Das Team entscheidet, ob das Element im weitesten erreichten Zustand gezählt bleibt oder zurückfällt, und wendet dieselbe Regel bei jeder Zählung an.

Das Diagramm sagt kein Fertigstellungsdatum voraus. Wer die Kurve "Erledigt" bis zu einem festen Umfang verlängert, zeichnet ein Burn-up-Chart. Eine Zusage zur Durchlaufzeit gegenüber einem Auftraggeber stützt sich auf die Verteilung der gemessenen Durchlaufzeiten. Das Team sortiert die Durchlaufzeiten der gelieferten Elemente und nimmt den Wert, unter dem 85 % von ihnen liegen: "85 % der Anfragen in 12 Tagen oder weniger geliefert". Der Mittelwert, im Streudiagramm unten etwa 8 Tage, taugt nicht als Zusage: Mehr als ein Drittel der Anfragen dauert länger.

Ein zum Ziel erhobener Durchsatz wird manipuliert. Ein Team, das am Durchsatz gemessen wird, zerlegt seine Elemente in kleinere. Der Durchsatz steigt, und der Auftraggeber erhält nichts früher. Wer zwei Teams am Durchsatz vergleicht, vergleicht ihre Art zu zerlegen.

KI-Überlegungen

Ein Sprachmodell schreibt das Skript oder die Tabellenformeln, die einen Export der Historie mit Kennung, Zustand und Übergangsdatum in kumulierte Zählungen pro Tag und Zustand umwandeln und daraus das Diagramm zeichnen. Die Analystin prüft das Ergebnis. Sie zählt im Export von Hand die Elemente eines gewählten Tages. Über ein stabiles Zeitfenster teilt sie die mittlere laufende Arbeit durch den Durchsatz und muss auf die mittlere Durchlaufzeit kommen, die Element für Element berechnet wurde.

Das Modell beschreibt auch ein Diagramm: Es nennt das breiter werdende Band und die Woche, in der die Kurve "Erledigt" abflacht. Die Ursache entgeht ihm. Eine abwesende Reviewerin, eine nicht verfügbare Testumgebung und ein Release-Freeze zeichnen dasselbe Band. Das Team findet die Ursache in der Retrospektive.

Der Export eines Tracking-Werkzeugs enthält die Titel und Beschreibungen der Anfragen, manchmal mit Namen von Kundinnen und Kunden oder von Versicherten. Die Berechnung braucht Kennung, Typ, Zustand und Übergangsdaten. Der Rest geht an keinen Dienst, dessen Nutzungsbedingungen die Organisation nicht kontrolliert.

Beispiele

Das Applikationsteam einer Pensionskasse bearbeitet über vier Wochen Änderungsanträge, mit einem einzigen Reviewer. Es erfasst die Zustände täglich. Die Tabelle zeigt die Freitage, ausgehend vom Anfangszustand am Freitag vor Woche 1.

In den Wochen 1 und 2 ist der Fluss stabil: 12 zugesagte Elemente, 6 Lieferungen pro Woche, also eine mittlere Durchlaufzeit von 2 Wochen. Das Diagramm bestätigt es: Die Zusagekurve erreicht 12 am Freitag von W0, die Kurve "Erledigt" am Freitag von W2, zehn Arbeitstage später. In Woche 3 fehlt der Reviewer zwei Tage. Das Band "Im Review" wird breiter, der Durchsatz fällt auf 3 und die laufende Arbeit steigt auf 15. Die Wochen 3 und 4 sind instabil: Das Diagramm zeigt die Verschlechterung, Littles Gesetz liefert nur eine Projektion. Kehrt der Durchsatz auf 6 pro Woche zurück, kündigt eine laufende Arbeit von 15 eine Durchlaufzeit von 2,5 Wochen an. Am Montag von W4 begrenzt das Team "Umsetzung" auf 3 Elemente und "Im Review" auf 4, und zwei Entwickler wechseln ins Review.

Am Freitag von W4 beträgt die laufende Arbeit 7: Kehrt der Durchsatz auf 6 zurück, liegt die projizierte Durchlaufzeit bei 7 ÷ 6, etwas mehr als einer Woche. Das 24. Element, das an diesem Tag geliefert wurde, war am Freitag von W2 zugesagt worden: zehn Tage. Es hat den Engpass durchlaufen. Die gemessene Durchlaufzeit sinkt erst, wenn die vor den Limiten zugesagten Elemente das System verlassen haben.

Visualisierungen

Jeder Zustand behält seine Farbe von einem Diagramm zum nächsten, und die senkrechte Achse beginnt am ersten Tag des Zeitfensters bei null. Die Anmerkungen zeigen, was die Leserin sehen soll: einen senkrechten Abstand als laufende Arbeit, einen waagrechten Abstand als Durchlaufzeit, das breiter werdende Band mit seinem Namen.

Das Streudiagramm der Durchlaufzeiten trägt jedes gelieferte Element nach Lieferdatum und Durchlaufzeit ein, mit den Linien des 50. und des 85. Perzentils: Es zeigt die Elemente, die die Mittelwerte des Diagramms verbergen. Das Histogramm der Durchlaufzeiten liefert die Verteilung, auf die sich eine Zusage zur Durchlaufzeit stützt.

Aufwand

Werkzeuge

Tracking-Werkzeuge zeichnen das Diagramm aus ihrer Historie: Jira in seinen Board-Berichten, Azure DevOps in einem Widget, Businessmap (vormals Kanbanize) in seinen Analysen. Sie eignen sich, sobald das Team sein Board darin führt. Vor der ersten Auswertung prüft das Team in ihrer Dokumentation, wie sie Durchlaufzeit und Zykluszeit definieren.

Erweiterungen wie ActionableAgile Analytics ergänzen das Streudiagramm der Durchlaufzeiten, die Perzentile und das Alter der offenen Elemente.

Eine Tabellenkalkulation genügt für ein Team ohne Werkzeug oder zur Kontrolle eines Werkzeugs: eine Zeile pro Element mit seinen Übergangsdaten, eine Pivot-Tabelle, die pro Tag und Zustand zählt, ein gestapeltes Flächendiagramm. Ein Python-Skript mit pandas und matplotlib leistet dasselbe auf einem Export und lässt sich versionieren.

Quellen

• David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010: das kumulative Flussdiagramm und die Durchlaufzeit als Steuerungsgrössen eines Kanban-Systems.
• Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing, 2009, Prinzipien Q11 The Cumulative Flow Principle und Q12 Little's Formula: die kumulierten Kurven der Ankünfte und Abgänge, der senkrechte Abstand als Warteschlange, der waagrechte Abstand als Wartezeit, dann Littles Formel.
• Wolfram MathWorld, "Little's Law": die Aussage L = λW und ihre Zuschreibung an John D. C. Little.