Kollabe
Rückschauen
Planungspoker
Standups
Eisbrecher
Preise
Armaturenbrett

Beiträge

Flow-Metriken für Scrum-Teams: Cycle Time, Throughput und was Sie wirklich messen sollten

Agile team gathered around a board with flowing streams of work items moving through columns, illustrated in a modern flat style with bright colors
Matt Lewandowski

Matt Lewandowski

Zuletzt aktualisiert am 10/02/20268 Min. Lesezeit

Ihr Team verfolgt Velocity. Sie sprechen darüber in der Sprint-Planung, erwähnen es vielleicht in Retros. Aber wenn ein Stakeholder fragt "Wann wird das fertig sein?", schätzen Sie immer noch. Velocity sagt Ihnen, wie viel Sie geschätzt haben zu erledigen, nicht wie lange Dinge tatsächlich dauern oder wo Arbeit feststeckt. Flow-Metriken schließen diese Lücke. Sie messen, was tatsächlich in Ihrem Prozess passiert, anhand echter Daten, nicht Schätzungen. Und Sie müssen nicht Scrum aufgeben oder "auf Kanban umsteigen", um sie zu nutzen.

Die vier Metriken, die zählen

Der Kanban Guide for Scrum Teams (veröffentlicht von Scrum.org) definiert vier Flow-Metriken. Hier ist, was jede einzelne Ihnen sagt und warum es sich lohnt, sie zu verfolgen.

Work in Progress (WIP)

Die Anzahl der Einträge, die Ihr Team begonnen, aber noch nicht abgeschlossen hat. Keine Formeln, nur eine Zahl. WIP ist wichtig wegen einer einfachen Wahrheit: Je mehr Dinge Sie jonglieren, desto länger dauert alles. Kontextwechsel, Übergaben und Wartezeiten nehmen alle mit höherem WIP zu. Die meisten Teams sind überrascht, wenn sie zum ersten Mal ihr tatsächliches WIP zählen.

Cycle Time

Die verstrichene Kalenderzeit vom Beginn der Arbeit bis zum Abschluss. Nicht Aufwandsstunden, sondern Wanduhrzeit. Cycle Time ist ein nachlaufender Indikator. Sie kennen ihn erst, nachdem ein Eintrag abgeschlossen ist. Aber sammeln Sie genug Datenpunkte (streben Sie 30+ an) und Sie können Dinge sagen wie "85% unserer Einträge werden in 10 Tagen oder weniger abgeschlossen." Das ist ein Service Level Expectation (SLE), und es ist weitaus nützlicher als eine auf Velocity basierende Schätzung.

Throughput

Die Anzahl der Einträge, die Ihr Team pro Zeiteinheit abschließt, typischerweise pro Sprint oder pro Woche. Throughput ist eine Zählung abgeschlossener Einträge unabhängig von der Größe. Eine 3-Punkt-Story und eine 8-Punkt-Story zählen jeweils als eins. Das klingt wie eine Einschränkung, ist aber tatsächlich eine Stärke: Es umgeht alle Debatten darüber, ob Ihre Punkte "genau" sind und misst, was Sie tatsächlich geliefert haben.

Work Item Age

Die verstrichene Zeit seit dem Start eines laufenden Eintrags. Betrachten Sie es als Cycle Time für Dinge, die noch nicht fertig sind. Dies ist die eine Metrik, die Sie täglich überprüfen sollten. Wenn das Alter eines Eintrags sich Ihrer typischen Cycle Time nähert und er noch weit vom Abschluss entfernt ist, ist das ein Frühwarnsignal. Sobald der Eintrag abgeschlossen ist, wird sein Alter zu seiner Cycle Time. Bis dahin ist es Ihr bester Frühindikator. Illustrated dashboard showing four colorful metric cards for WIP, cycle time, throughput, and work item age with small chart icons on each

Wie diese Metriken zusammenhängen

Das Little'sche Gesetz verbindet die ersten drei: Durchschnittliches WIP = Durchschnittlicher Throughput × Durchschnittliche Cycle Time Das ist in der Praxis wichtig. Wenn Sie WIP reduzieren, ohne etwas anderes zu ändern, sinkt die Cycle Time. Ihr Team muss nicht schneller arbeiten. Es muss an weniger Dingen gleichzeitig arbeiten.
Wenn Sie ... möchtenDann ...
Cycle Time reduzierenSenken Sie Ihr WIP
Throughput erhöhenSchließen Sie aktuelle Arbeit ab, bevor Sie neue beginnen
Liefertermine vorhersagenVerwenden Sie Cycle-Time-Perzentile (SLEs)
Probleme früh erkennenBeobachten Sie Work Item Age täglich

Erste Schritte ohne Prozessumstellung

Sie brauchen keine neuen Tools oder eine Prozessumstellung. Hier ist ein praktischer Weg.
  1. Verfolgen Sie drei Daten pro Eintrag
    Erfassen Sie für jeden Product-Backlog-Eintrag, wann er erstellt wurde, wann die Arbeit begann und wann er fertig war. Die meisten Tools wie Jira und Azure DevOps erfassen dies bereits. Sie müssen nur anfangen, darauf zu achten.
  2. Definieren Sie Ihren Workflow explizit
    Schreiben Sie auf, was "begonnen" und "fertig" für Ihr Team bedeuten. Was sind die Spalten auf Ihrem Board? Was sind die Regeln für das Verschieben von Einträgen zwischen ihnen? Das ist Ihre Definition of Workflow, und sie ist die Grundlage für konsistente Messung.
  3. Sammeln Sie Daten für einige Sprints
    Versuchen Sie noch nicht, etwas zu analysieren. Lassen Sie die Daten einfach akkumulieren. Sie benötigen mindestens 30 abgeschlossene Einträge für aussagekräftige Muster, was die meisten Teams in 3-4 Sprints erreichen.
  4. Erstellen Sie Ihr erstes Cycle-Time-Streudiagramm
    Zeichnen Sie jeden abgeschlossenen Eintrag mit seinem Abschlussdatum auf der x-Achse und der Cycle Time auf der y-Achse. Ziehen Sie horizontale Linien bei den 50., 85. und 95. Perzentilen. Ihr 85. Perzentil ist ein solider Ausgangspunkt für ein SLE.
  5. Bringen Sie es in Ihre Scrum-Events ein
    Verwenden Sie Throughput-Historie in der Sprint-Planung anstelle von (oder neben) Velocity. Überprüfen Sie Work Item Age in Daily Scrums. Überprüfen Sie Cycle-Time-Trends in Retrospektiven. Präsentieren Sie SLE-Performance in Sprint-Reviews.

Wo Flow-Metriken in jedes Scrum-Event passen

Diese Metriken werden nützlich, wenn Sie sie in Events einbinden, die Sie bereits durchführen. Sprint-Planung: Verwenden Sie Ihre Throughput-Historie, um vorherzusagen, wie viele Einträge Sie realistisch annehmen können. "Wir haben in den letzten 8 Sprints 6-9 Einträge pro Sprint abgeschlossen" ist fundierter als Story-Point-Summen zu debattieren. Für mehr über die Durchführung effektiver Planungssitzungen sehen Sie sich unseren Sprint-Planning-Leitfaden an. Daily Scrum: Wechseln Sie von Statusupdates zu Flow. "Was altert?" ist eine bessere Frage als "Was hast du gestern gemacht?" Wenn ein Eintrag 7 Tage alt ist und Ihre 85. Perzentil-Cycle-Time 10 Tage beträgt, sollte das Team sich darauf konzentrieren. Sprint Review: Zeigen Sie Stakeholdern Ihren Cycle-Time-Trend und die SLE-Performance. "Wir haben 85% der Einträge innerhalb von 10 Tagen in diesem Sprint geliefert, gegenüber 72% im letzten Monat" baut Vertrauen durch Transparenz auf. Sprint-Retrospektive: Hier zahlen sich Flow-Metriken am meisten aus. Ein Cumulative Flow Diagram zeigt Engpässe, die in einem Burndown-Chart unsichtbar sind, wie Arbeit, die sich in Code-Review staut, oder eine Testphase, die leidet, wenn QA in Meetings gezogen wird. Team members pointing at a large wall chart showing a cumulative flow diagram with colorful bands representing different workflow stages

Flow-Metriken vs. Velocity: kein Wettkampf

Velocity ist nicht kaputt, nur begrenzt. Es funktioniert gut als internes Planungstool für Sprint-Gespräche. Das Problem beginnt, wenn Teams es für Lieferzusagen verwenden, es über Teams hinweg vergleichen oder es als Leistungsmetrik behandeln. Flow-Metriken beantworten die Fragen, die Velocity nicht kann:
  • "Wann wird das fertig sein?" Cycle-Time-Perzentile geben probabilistische Antworten.
  • "Warum dauert alles so lange?" WIP und Work Item Age zeigen Ihnen, wo Arbeit feststeckt.
  • "Können wir uns auf dieses Datum verpflichten?" Monte-Carlo-Simulationen mit Throughput-Historie geben Ihnen Konfidenzniveaus.
Der praktische Ansatz: Verwenden Sie beides. Behalten Sie Velocity für die Sprint-Planung bei, wenn es für Ihr Team funktioniert. Fügen Sie Flow-Metriken für Lieferprognosen und Prozessverbesserung hinzu.

Fehler, die Teams stolpern lassen

Throughput auf Kosten von allem anderen optimieren. Teams zu drängen, mehr Einträge abzuschließen, führt dazu, kleine Arbeit herauszupicken, Stories künstlich aufzuteilen oder bei der Qualität Abstriche zu machen. Throughput ist ein Diagnosewerkzeug, kein Ziel. Work Item Age ignorieren, bis es zu spät ist. Cycle Time sagt Ihnen nur etwas über abgeschlossene Arbeit. Wenn Sie nicht auf das Alter laufender Einträge achten, verpassen Sie Warnsignale. Bringen Sie es auf Ihr Board oder erwähnen Sie es im Daily Scrum. Die Definition of Workflow überspringen. Ohne gemeinsames Verständnis dessen, was "begonnen" und "fertig" bedeuten, sind Ihre Daten inkonsistent und Ihre Metriken unzuverlässig. Es muss nicht perfekt sein, aber es muss existieren. Alles messen. Sie brauchen nicht 15 Diagramme. Die vier Flow-Metriken, ein Cycle-Time-Streudiagramm und vielleicht ein Cumulative Flow Diagram decken 90% dessen ab, was Sie brauchen. Fügen Sie Komplexität nur hinzu, wenn Sie eine spezifische Frage zu beantworten haben.

Wie gutes Aussehen nach einigen Monaten aussieht

Teams, die 3-6 Monate bei Flow-Metriken bleiben, bemerken tendenziell einige Dinge. Die Sprint-Planung wird schneller, weil Throughput einen klaren Ausgangspunkt für Kapazität bietet. Retros produzieren spezifischere Aktionspunkte, weil Sie Daten statt Bauchgefühle betrachten. Die größte Veränderung ist normalerweise kulturell. Teams hören auf, über das Beginnen von Arbeit nachzudenken und beginnen, über das Beenden nachzudenken. Die Frage verschiebt sich von "Was soll ich als Nächstes aufnehmen?" zu "Was kann ich helfen, über die Ziellinie zu bringen?" Das ist die Verschiebung, die tatsächlich etwas bewirkt. Tools wie Kollabes Planning Poker helfen bei der Schätzungsseite der Sprint-Planung, aber Flow-Metriken geben Ihnen die Liefervorhersagbarkeit, die Schätzung allein nicht bieten kann.

Ja. Viele Teams verwenden beides. Story Points können weiterhin Sprint-Planungsgespräche antreiben, während Flow-Metriken Prognosen und Prozessverbesserung übernehmen. Im Laufe der Zeit stellen einige Teams fest, dass sie weniger auf Punkte angewiesen sind, aber es gibt keinen Grund, einen Übergang zu erzwingen.

Die meisten Teams können mit Jira oder Azure DevOps beginnen, die beide integrierte Cycle-Time-Reports und Cumulative Flow Diagrams haben. Für tiefere Analysen ist ActionableAgile Analytics (verfügbar als Jira/Azure DevOps-Plugin) das bevorzugte Tool.

Streben Sie 30+ abgeschlossene Einträge für statistisch aussagekräftige Cycle-Time-Perzentile an. Die meisten Teams erreichen dies in 3-4 Sprints. Work Item Age ist sofort nützlich, da es keine historischen Daten benötigt.

Ja. Der Kanban Guide for Scrum Teams wurde von Scrum.org speziell veröffentlicht, um diese Praktiken in Scrum zu bringen. Sie müssen Kanban nicht übernehmen, nur die Daten verfolgen, die Ihr Prozess bereits generiert.