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.
Wenn du das Cockpit zum ersten Mal öffnest oder wenig Zeit hast, lies in dieser Reihenfolge. Jeder Schritt beantwortet eine Frage, und jede Antwort führt zur nächsten.
Die eine Regel dahinter: erst den Fluss ansehen, dann die Menge. Ein Team, das weniger gleichzeitig anfängt, liefert messbar früher — auch ohne mehr zu arbeiten.
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.
Wo im Alltag: Weekly Flow Review (Mo) als Einstieg — ein Blick, und die Engstelle der Woche liegt auf dem Tisch. Im PI-Review als Verlaufsbild über den ganzen Zeitraum.
Was du daraus machst: Das dickste Band benennen und fragen „was hindert diese Arbeit am Weitergehen?". Wird das Done-Band flacher, obwohl oben gleich viel reinkommt, wächst euer Bestand — dann WIP-Limit senken statt Druck erhöhen.
Typische Fehldeutung: Ein breites Band heißt nicht „viel geschafft", sondern „viel liegt hier". Breite ist Bestand, nur die Steigung unten ist Leistung.
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.
Wo im Alltag: Im Daily, bevor jemand etwas Neues zieht. Im Weekly, wenn über Zusagen gesprochen wird.
Was du daraus machst: Rechne es einmal laut vor: 20 Tickets in Arbeit bei 5 fertigen pro Woche sind vier Wochen Durchlaufzeit — egal wie fleißig alle sind. Danach diskutiert niemand mehr über Motivation, sondern über das WIP-Limit.
Typische Fehldeutung: „In Review" wird gern übersehen, weil es sich nach „fast fertig" anfühlt. Ein volles Review-Feld ist aber ein Stau, kein Erfolg — dort wartet Arbeit auf Menschen, nicht auf Können.
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.
Wo im Alltag: Immer dann, wenn jemand „wann ist das fertig?" fragt — im Refinement, gegenüber Stakeholdern, in der Roadmap-Abstimmung.
Was du daraus machst: Sag nicht „ungefähr zwei Wochen", sondern „in 85 % der Fälle innerhalb von X Tagen". Das ist ehrlicher, verhandelbar und lässt sich nachprüfen. Punkte weit oben einzeln ansehen: Was war bei diesen Tickets anders? Meist eine Abhängigkeit, keine Komplexität.
Typische Fehldeutung: Den Median als Zusage benutzen. Der p50 trifft per Definition in der Hälfte der Fälle nicht zu — wer damit plant, ist jede zweite Woche zu spät.
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.
Wo im Alltag: Weekly Flow Review als erste Zahl. In Kapazitätsgesprächen mit dem Management — Throughput ist die einzige Liefergröße, die nicht geschätzt ist.
Was du daraus machst: Aus dem Throughput wird die Prognose: Zwölf offene Tickets bei fünf pro Woche sind gut zwei Wochen. Steht Created dauerhaft über Resolved, ist die richtige Maßnahme Zufluss begrenzen — Priorisierung an der Quelle, nicht Überstunden am Ende.
Typische Fehldeutung: Eine Spitzenwoche als neue Normalgeschwindigkeit lesen. Der Takt zählt, nicht der Rekord; Schwankung ist selbst eine Kennzahl.
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.
Wo im Alltag: Das Herzstück des Dailys. Board von rechts nach links lesen, ältestes Ticket zuerst — nicht reihum berichten, wer was tut.
Was du daraus machst: Für die älteste Karte genau eine Entscheidung treffen: zerlegen, jemanden dazuholen, bewusst zurücklegen. Alles davon ist besser, als sie noch eine Woche mitzuschleppen. Vergleiche das Alter mit eurem p85 — was älter ist als p85, wird mit hoher Wahrscheinlichkeit nicht mehr „normal" fertig.
Typische Fehldeutung: Alter mit Aufwand verwechseln. Die meisten alten Tickets sind nicht schwer, sondern blockiert — die Frage lautet „worauf wartet es?", nicht „wer ist zu langsam?".
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 %.
Wo im Alltag: In der Retro, wenn das Team das Gefühl hat, ständig zu arbeiten und trotzdem nichts fertig zu bekommen. Diese Kachel erklärt das Gefühl.
Was du daraus machst: Bei 15 % ist der Hebel nicht „schneller tippen", sondern die 85 % Wartezeit: fehlende Zuarbeit, Freigaben, Übergaben, Review-Schlangen. Such die längste Wartestrecke und mach sie sichtbar — als eigene Spalte oder als Blocker.
Typische Fehldeutung: Den Wert als Fleiß-Note lesen. Er misst das System, nicht die Menschen; 15 % ist der Branchenschnitt, nicht ein Versagen.
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.
Wo im Alltag: Due Date im Stakeholder-Gespräch, Class of Service im Refinement, Work Item Type in der Retro und in der PI-Planung.
Was du daraus machst: Nutzt ihr nur „Standard", priorisiert ihr trotzdem — nur unausgesprochen, im Kopf einzelner. Klassen sichtbar zu machen ersetzt zehn Dringlichkeitsdiskussionen. Beim Ticket-Mix: Ist der Wartungsanteil dauerhaft hoch, ist das eine Kapazitätsaussage, keine Fleißaussage.
Typische Fehldeutung: Termintreue ohne Kontext feiern. Bei weniger als drei Terminen ist die Kachel grau — dann sagt sie nichts, und das ist ehrlicher als eine schöne Zahl.
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 %.
Wo im Alltag: Refinement-KPI vor dem Refinement-Termin, SLAs im Service-Review mit den Auftraggebern.
Was du daraus machst: Eine niedrige Refinement-Quote sagt voraus, dass das nächste Ziehen holprig wird — unklare Tickets werden zu Rückfragen, Rückfragen zu Wartezeit. Zwei Stunden Refinement kosten weniger als zwei Wochen Warten.
Typische Fehldeutung: Die Quote als Zielgröße jagen. Sie ist ein Frühindikator, kein Ergebnis — 100 % refined bei falscher Reihenfolge hilft niemandem.
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