Warum sie wichtig ist: Cycle Time ist die direkte Messung deiner Liefergeschwindigkeit. Kurze, konsistente Cycle Times signalisieren ein stabiles, vorhersehbares System. Hohe Varianz in der Cycle Time — manche Aufgaben dauern 2 Tage, andere 30 Tage — ist ein klares Zeichen für systemische Probleme: zu viel parallele Arbeit, unklare Definitionen of Done oder versteckte Abhängigkeiten.

Häufiger Fehler: Cycle Time mit Lead Time verwechseln. Cycle Time misst interne Effizienz. Lead Time misst die Kundenperspektive. Beides ist wichtig, aber aus unterschiedlichen Gründen.

Warum sie wichtig ist: Lead Time ist die Metrik, die Kunden und Stakeholder tatsächlich wahrnehmen. Ein Team mit kurzer Cycle Time, aber langer Wartezeit hat ein WIP-Problem — es arbeitet schnell, sobald es anfängt, aber Aufgaben warten zu lange in der Queue.

Häufiger Fehler: Lead Time ausschließlich als "zu lang" zu betrachten, ohne die Zusammensetzung zu analysieren. Wenn die Lead Time 20 Tage beträgt und die Cycle Time 3 Tage, liegt das Problem nicht in der Ausführung, sondern im System vor der Ausführung — zu viele parallele Aufgaben, zu wenig Kapazität, falsche Priorisierung.

In Jira: Ebenfalls im Control Chart verfügbar — umschaltbar zwischen Cycle Time und Lead Time.

Warum sie wichtig ist: Throughput ist die wichtigste Metrik für Vorhersagen und Planung. Wer weiß, dass sein Team durchschnittlich 8 Aufgaben pro Woche abschließt, kann realistische Liefertermine für Projekte berechnen — ohne Schätzungen oder Planning Poker. In Kombination mit Monte-Carlo-Simulationen wird Throughput zur Grundlage probabilistischer Forecasts.

Häufiger Fehler: Throughput mit Produktivität gleichsetzen. Hoher Throughput bedeutet nicht, dass das Team die richtigen Dinge liefert. Throughput muss immer in Kombination mit der Qualität der gelieferten Items betrachtet werden.

In Jira: Im Bereich "Insights" bei Jira-Software-Projekten als "Throughput"-Report verfügbar. Alternativ lässt sich Throughput einfach aus dem Backlog exportieren und in Excel berechnen.

Warum sie wichtig ist: WIP ist der stärkste Hebel für Flow-Verbesserung. Das Littlesche Gesetz zeigt mathematisch: Cycle Time = WIP / Throughput. Wer WIP reduziert, ohne Throughput zu verringern, senkt automatisch die Cycle Time. WIP-Limits sind deshalb keine willkürlichen Regeln, sondern systemische Hebel.

Häufiger Fehler: WIP-Limits setzen und dann ignorieren. In der Praxis übersteigen Teams ihre WIP-Limits regelmäßig, ohne darüber zu sprechen. Das ist ein klares Signal, dass die Limits entweder falsch kalibriert sind oder dass das Team die Logik dahinter nicht verstanden hat.

In Jira: WIP ist in jedem Kanban-Board direkt sichtbar — die Anzahl der Karten pro Spalte. Jira erlaubt auch das Setzen von Column-Limits, die visuell angezeigt werden.

Warum sie wichtig ist: Work Item Age ist ein Frühindikator. Während Cycle Time eine historische Metrik ist (was war), ist Work Item Age eine gegenwärtige Metrik (was ist gerade). Aufgaben mit hohem Work Item Age — die deutlich älter sind als die durchschnittliche Cycle Time — sind potenzielle Probleme, die sofort Aufmerksamkeit brauchen.

Häufiger Fehler: Work Item Age mit Cycle Time verwechseln oder zusammenführen. Cycle Time ist eine abgeschlossene Aufgabe. Work Item Age ist eine laufende Aufgabe. Sie messen unterschiedliche Phasen.

In Jira: Nicht nativ als separater Report vorhanden. Kann über JQL berechnet werden (created-Datum vs. aktuelles Datum für Karten im Status "In Progress"). Einfacher: Im Aging WIP Chart, der Work Item Age visuell darstellt.

Warum er wichtig ist: Der Aging WIP Chart ist zusammen mit dem Cycle Time Scatterplot das wichtigste tägliche Steuerungsinstrument für Kanban-Teams. Er zeigt sofort, welche Aufgaben das System gerade blockieren — also welche Aufgaben älter sind als 85 % der historisch abgeschlossenen Aufgaben. Das sind die Aufgaben, die im Daily oder im Replenishment Meeting besprochen werden sollten.

Häufiger Fehler: Den Chart nur wöchentlich anschauen statt täglich. Aufgaben, die über ihre SLE-Grenze hinausgehen, brauchen sofortige Aufmerksamkeit, nicht eine wöchentliche Retrospektive.

In Jira: Nicht nativ vorhanden. Verfügbar über das ActionableAgile-Plugin für Jira oder über externe Tools wie nave.pro oder Kanbanize. Alternativ manuell in Excel aufgebaut — weniger elegant, aber funktional.

Warum sie wichtig ist: SLE ist die datenbasierte Alternative zu Schätzungen und Deadlines. Statt "Wir glauben, das dauert 2 Wochen" sagt das Team: "Basierend auf unseren historischen Daten können wir mit 85-prozentiger Wahrscheinlichkeit sagen, dass dies innerhalb von 10 Tagen fertig ist." Das schafft Vertrauen bei Stakeholdern, weil es auf echten Daten basiert statt auf Bauchgefühl.

Häufiger Fehler: SLE ohne ausreichende Datenbasis definieren. Eine SLE braucht mindestens 50 bis 100 abgeschlossene Aufgaben als historische Grundlage, um statistisch valide zu sein. Teams, die nach zwei Wochen eine SLE definieren, messen Rauschen, nicht Signal.

In Jira: Die Datenbasis für SLE-Berechnungen liegt im Control Chart. Die eigentliche SLE-Berechnung erfolgt typischerweise extern — in ActionableAgile, nave.pro oder manuell in Excel über Percentile-Berechnungen.

Warum sie wichtig ist: Flow Efficiency ist die schonungsloseste Metrik in der Liste. Die meisten Teams haben eine Flow Efficiency von 15 bis 40 % — das bedeutet, dass die Mehrheit der Zeit, die eine Aufgabe im System verbringt, Wartezeit ist, keine aktive Bearbeitung. Das zeigt systemische Engpässe: zu viele Übergaben, zu viele Abhängigkeiten, zu wenig parallele Kapazität.

Häufiger Fehler: Flow Efficiency als Ziel von 100 % anstreben. Das ist nicht realistisch und auch nicht sinnvoll — Teams brauchen Puffer und Slack für unvorhergesehene Arbeit. Ein realistisches Ziel liegt zwischen 40 und 60 %.

In Jira: Nicht nativ verfügbar. Erfordert Time-in-Status-Daten, die über JQL oder externe Plugins (wie Time in Status für Jira) exportiert werden müssen. Dann Berechnung in Excel.