Was vorher fertig sein muss
Der Arbeitsfluss ist verstanden, Hauptstufen und Handoffs sind bekannt, sodass die Kanban-Spalten echte Stufen abbilden.
Team akzeptiert ein gemeinsames sichtbares Board als zentrale Quelle der Wahrheit fuer laufende Arbeit.
Was vor Start vorliegen muss
Physisches Board oder digitales Tool (Jira, Linear, Trello, Azure Boards); Karten-Schema mit Titel, Owner, Class of Service, Faelligkeit; WIP-Limit-Beschilderung pro Spalte; Cumulative Flow Diagram (CFD) als Reporting.
Ein Service Delivery Manager oder Team Lead als Owner des Flows; alle Teammitglieder als Karten-Verschieber; optionaler Flow Manager fuer Multi-Team-Setups; Stakeholder mit Read-Zugriff.
Backlog mit ausstehenden Items; Definition of Ready und Definition of Done pro Spalte; aktuelle Auslastung pro Person; bekannte externe Abhaengigkeiten; SLA- oder Lieferziele.
Setup 2-4 h, danach kontinuierlich mit taeglichem Stand-up (15 min) und woechentlichem Replenishment (45 min)
Spalten an realen Arbeitsschritten ausrichten (z. B. Backlog, Ready, In Progress, In Review, Done). WIP-Limits pro Spalte konservativ setzen (Personen pro Spalte minus 1). Definition of Done pro Spalte schriftlich. Class of Service definieren (Standard, Expedite, Fixed Date, Intangible).
Die eine Frage, die diese Methode beantwortet
Wie fliesst Arbeit durch die Stufen, wo staut es sich, und welche Policy haelt das WIP-Limit ein?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Visualisieren | 2-4 h Setup | Alle laufenden Items als Karten erfassen und in die passende Spalte einsortieren. Owner pro Karte. Class of Service kennzeichnen. Board fuer alle sichtbar machen. | Wenn das Board nach dem Befuellen 30 In-Progress-Karten zeigt und das Team aus 5 Personen besteht, ist die Auslastung das primaere Problem, nicht der Prozess. |
2Phase 2: WIP-Limits setzen | 1 h | Pro Spalte ein hartes Limit beschliessen. Faustregel: Personen in der Spalte minus 1, oder konservativ 1.5 pro Person bei Pair Work. Limit muss auf dem Board sichtbar sein. | Wenn das Team das Limit als „Empfehlung“ verhandelt, gibt es kein Limit. Vor Einfuehrung explizit committen: bei Ueberschreitung Stop-the-Line. |
3Phase 3: Policies und Pull | 30 min | Pull-Regel verankern: niemand schiebt Arbeit, jeder zieht. Daily Stand-up am Board, von rechts nach links lesen. Blocker als rote Karte markieren. Eskalation klar regeln. | Wenn ein Manager Arbeit auf das Board pusht, ohne dass jemand Kapazitaet hat, sind WIP-Limits wirkungslos. Manager bringt Items in Replenishment, nicht direkt in Doing. |
4Phase 4: Messen und visualisieren | fortlaufend | Cumulative Flow Diagram (CFD) und Lead Time pro Karte tracken. Lead Time Histogramm als Forecast-Basis. Monatlicher Flow Review mit Bottleneck-Analyse. | Lead Time ohne Verteilung verschleiert. Median und 85.-Perzentil reporten. Wenn Lead Time stark streut, ist Class of Service unklar oder Items zu unterschiedlich gross. |
5Phase 5: Kontinuierliche Verbesserung | 45 min pro Monat | Flow Review: wo entstehen Wartezeiten, wo brechen WIP-Limits, welche Class of Service ist ueberlastet. Ein bis zwei Verbesserungs-Massnahmen pro Review. | Kanban ist kein Set-and-Forget. Ohne Review wird das Board ein Tracker, kein Steuerungsinstrument. Maximal zwei Aenderungen pro Review, sonst verliert man Wirkungskausalitaet. |
Was am Ende rauskommt
Lebendes Kanban-Board mit Spalten, WIP-Limits, Klassen, Karten und Policies, plus Cumulative Flow Diagram, Lead Time Histogramm und Monats-Review-Notizen mit Verbesserungen und Outcomes.
Board-Konfiguration als Code wo moeglich (Jira Configuration Export). Monats-Snapshot des CFD und Lead-Time-Histogramms in Confluence oder Wiki. Aenderungen an Spalten oder WIP-Limits mit Datum und Begruendung dokumentieren.
Kompakte Arbeitsvorlage für Kanban mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Kanban Canvas
## Kontext
Wofür wird die Methode eingesetzt?
## Kernfrage
Welche Frage soll am Ende beantwortet sein?
## Input
Welche Daten, Beobachtungen oder Materialien liegen vor?
## Arbeitsfläche
- Bereich 1:
- Bereich 2:
- Bereich 3:
- Beziehungen / Muster:
## Ergebnisartefakte
- Kanban Board:
- WIP Policies:
- Flow Metrics:
## Offene Fragen
- ...
## Nächster Schritt
Owner, Datum, Erfolgssignal.Konkret gefülltes Szenario
## Kanban-Board Plattform-Team Workspot, Stand 18.05.2026
**Spalten und Limits**
- Backlog (kein Limit)
- Ready (max 8)
- In Progress (max 4)
- In Review (max 3)
- Verify (max 2)
- Done
**Classes of Service**
- Standard (gelb), Expedite (rot, 1 Slot reserviert), Fixed Date (blau), Intangible (grau).
**Aktueller Stand**
- Backlog: 27 Items. In Progress: 4 (Limit erreicht). In Review: 4 (Limit ueberschritten +1, Stop-the-Line).
**Flow-Metriken (rolling 4 Wochen)**
- Throughput: 11.2 Items/Woche.
- Lead Time Median: 6.4 Tage, 85. Perzentil: 18.2 Tage.
- Block-Quote: 9% der Items mindestens einmal blockiert.
**Top-Engpass**: In Review (Reviewer-Kapazitaet). Massnahme ab KW 19: Pair-Review-Slot Di/Do 14:00-15:30, Owner @ben. Erfolgsindikator: 85.-Perzentil Lead Time auf unter 14 Tage in 6 Wochen.Symptome erkennen, gegensteuern
Spalten heissen „To Do, Doing, Done“ und bilden die echten Stufen nicht ab; Karten haengen ewig in „Doing“.
Spalten an realer Arbeit ausrichten, mindestens Ready, In Progress, In Review, Verify. Jede Spalte mit Eingangs- und Ausgangskriterium.
Limit von 3 wird regelmaessig auf 5 oder 6 ueberzogen, keine Reaktion.
Stop-the-Line einfuehren: bei Ueberschreitung darf nichts Neues gestartet werden. Bestehende Item zuerst durchziehen. Kultur erst, wenn Limit als Vereinbarung gilt.
Manager oder PM schieben Karten in die Doing-Spalte, ohne dass jemand Kapazitaet hat.
Replenishment-Meeting als einzigen Weg in Ready definieren. Doing bleibt Pull-only. Bei Druck von oben Class of Service Expedite mit klaren Regeln nutzen, nicht informelle Eskalation.
Mehrere Personen denken, jemand anderes arbeite daran, Karten stagnieren.
Pull-Regel: wer zieht, ist Owner. Owner-Avatar pflicht. Wenn keine Person zieht, bleibt Karte in Ready, kein Default-Owner.
Alle Karten sehen gleich aus, Expedite-Tickets verdraengen Standardarbeit ohne Regel.
Vier Klassen definieren mit Slots und Regeln. Expedite hat ein Slot, blockiert nicht den ganzen Flow. Fixed Date hat Faelligkeit auf der Karte.
Diagramm existiert, niemand schaut es an, Engpaesse bleiben unbemerkt.
Monthly Flow Review als wiederkehrender Termin. CFD und Lead Time Histogramm sind Pflichtfolien. Ein Engpass pro Review wird angegangen.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.