Dieses Dashboard macht den Arbeitsfluss eures Kanban-Systems sichtbar — nicht die Auslastung einzelner Personen, sondern wie gut Arbeit durch das System fließt. Alle Werte werden clientseitig aus den eingebetteten Jira-Rohdaten berechnet; Epics sind als Container ausgeschlossen.
Zeigt für jeden Zeitpunkt, wie viele Tickets in welcher Spalte liegen (kumulativ gestapelt: Done unten, Discovery oben). Rekonstruiert aus den Status-Changelogs jedes Tickets zu 8 Schnittzeitpunkten im gewählten Zeitraum. Lesart: Laufen die Bänder parallel, ist der Fluss stabil. Wird ein Band dicker, staut sich dort Arbeit. Die Steigung des Done-Bands ist eure Liefergeschwindigkeit.
Momentaufnahme zum Enddatum des Zeitraums: Wie viele Tickets stehen in Discovery, Ready, In Progress, In Review? Nach Little's Law gilt: Durchlaufzeit ≈ Bestand ÷ Durchsatz. Viel WIP bedeutet mathematisch zwingend lange Wartezeiten.
Jeder Punkt ist ein abgeschlossenes Ticket; die Höhe zeigt die Tage von Erstellung bis Abschluss. Die Linien markieren Perzentile: p50 (Median), p85, p95 — „85 % unserer Tickets waren in X Tagen fertig". Das Verhältnis p85/p50 misst die Vorhersagbarkeit: je größer, desto unzuverlässiger sind Prognosen. Das Histogramm zeigt dieselben Daten als Verteilung.
Throughput = erledigte Tickets pro Woche (eure echte Liefergeschwindigkeit — stabiler Takt schlägt Spitzenwochen). Created vs. Resolved vergleicht Zufluss und Abfluss: Kommt mehr rein als raus, wächst das System und alle Durchlaufzeiten steigen.
Alter der aktuell laufenden Tickets. Alte laufende Tickets sind das größte Risiko im System: Sie binden Kapazität, veralten fachlich und verstopfen den Fluss.
Anteil echter Arbeitszeit an der Gesamtdurchlaufzeit. Wir schätzen sie aus der Status-Historie: Zeit in „In Progress" + „In Review" ÷ Zeit von Erstellung bis Abschluss, summiert über alle im Zeitraum erledigten Tickets. Branchentypisch sind nur ~15 % — der Rest ist Warten. Exakte Werte bräuchten explizite Warte-Status. Schwellen: ≥ 40 % · ≥ 15 % · < 15 %.
Due Date: Termintreue der erledigten Tickets mit Fälligkeitsdatum (grau bei < 3 Terminen). Class of Service: Dringlichkeitsklassen (Expedite/Fixed Date/Intangible/Standard) — ungenutzte Klassen bedeuten unsichtbare Priorisierung. Work Item Type: Ticket-Mix der aktiven Arbeit, ohne Epics.
Refinement: Tickets mit Label refinement_needed (offen) vs. refinement_done; Quote = done ÷ (needed + done), grün ab 70 %. SUP-SLAs: Anteil der Vorgänge im SLA-Ziel (met = completed − everBreached), grün ab 85 %.
Der Score fasst alle bewerteten Kacheln des Gesamtsystems zu einer Zahl zusammen:
Score = 100 × (🟢 + 0,5 × 🟡) ÷ (🟢 + 🟡 + 🔴)
Jede grüne Kachel zählt voll, jede gelbe halb, rote gar nicht; ⚪-Info-Kacheln zählen nicht mit. Beispiel: 0×🟢, 7×🟡, 6×🔴 → 100 × 3,5 ÷ 13 = 27/100. Der Score ist bewusst streng: Er steigt nur, wenn Kacheln die datengetriebenen Schwellen erreichen — jede Verbesserung von Rot auf Gelb bringt sofort Punkte.
| Kachel | Kennzahl | 🟢 grün | 🟡 gelb | 🔴 rot |
|---|---|---|---|---|
| WIP | Bestand ÷ Ø-Wochendurchsatz (Little's Law) | ≤ 1,5 Wo. | ≤ 3 Wo. | > 3 Wo. |
| Scatterplot | Vorhersagbarkeit p85 ÷ p50 | ≤ 2 | ≤ 3 | > 3 |
| Histogramm | Anteil Langläufer > 120 T | < 5 % | < 15 % | ≥ 15 % |
| Throughput | Schwankung (Variationskoeffizient) | ≤ 30 % | ≤ 60 % | > 60 % |
| Created vs. Resolved | Netto-Zufluss ggü. Abfluss | ≤ 0 % | ≤ 20 % | > 20 % |
| Aging | Anteil laufender Tickets > 30 T | < 30 % | < 50 % | ≥ 50 % |
| Due Date | Pünktlich-Quote (grau bei < 3 Terminen) | ≥ 80 % | ≥ 60 % | < 60 % |
| Flow Efficiency | aktive Zeit ÷ Durchlaufzeit (Schätzung) | ≥ 40 % | ≥ 15 % | < 15 % |
| CFD | Wachstum des aktiven Bestands im Zeitraum | ≤ 0 % | ≤ 15 % | > 15 % |
| Refinement | done ÷ (needed + done) | ≥ 70 % | ≥ 40 % | < 40 % |
| SUP-SLA | Quote im Ziel | ≥ 85 % | ≥ 50 % | < 50 % |
Version 2.1.0 · 2.1: Vorperioden-Vergleich, Flow-Efficiency-Schätzung, zweisprachig DE/EN · 2.0: freier Zeitraum, Rohdaten-Engine, Epics ausgeschlossen, Personen-Modus, Flow-Coach · 1.x: datengetriebene Ampeln, Live-CFD, Refinement-KPI