Was ist Kanban im Projekt- und Teamalltag?
Kanban ist eine Methode, um den Fluss von Arbeit sichtbar zu machen, zu steuern und laufend zu verbessern. Anders als Scrum kennt Kanban keine festen Zyklen und keine vorgeschriebenen Rollen. Stattdessen wird Arbeit kontinuierlich gezogen: Ein neuer Eintrag wird erst begonnen, wenn Kapazität frei ist. Das eignet sich besonders für Teams mit vielen kleinen, unterschiedlich dringenden Aufträgen, etwa Support, Betrieb, Marketing oder Agenturen, aber auch für Entwicklungsteams, die einen gleichmässigen Fluss anstreben.
Der Kanban Guide beschreibt Kanban als Strategie zur Optimierung des Werteflusses durch einen visuellen, auf begrenzte gleichzeitige Arbeit ausgerichteten Pull-Prozess und nennt vier minimale Flussmetriken [1]. Er ist bewusst knapp und wurde mehrfach überarbeitet, zuletzt in einer Ausgabe vom Mai 2025 [2]. Wie Scrum lässt Kanban viel Raum für die konkrete Ausgestaltung.
Wie führen Sie Kanban in sechs Schritten ein?
- 1Arbeitsfluss beschreiben: Welche Schritte durchläuft ein Eintrag heute vom Eingang bis zur Fertigstellung? Wo beginnt und endet der Fluss?
- 2Board aufbauen: Für jeden Schritt eine Spalte, dazu Bereiche für Warten und Blockiert.
- 3Arbeit sichtbar machen: Alle laufenden Einträge auf das Board bringen, auch ungeplante.
- 4WIP-Limits festlegen: Für jede Spalte oder den gesamten Fluss eine Obergrenze gleichzeitig laufender Einträge.
- 5Flussmetriken messen: Start- und Enddatum jedes Eintrags erfassen, daraus WIP, Durchsatz, Work Item Age und Cycle Time ableiten.
- 6Regelmässig verbessern: Wöchentlich auf Engpässe, alte Einträge und Blockaden schauen und Experimente vereinbaren.
Ein wichtiger Grundsatz lautet: Starten Sie mit dem, was Sie heute tun. Das Board bildet den tatsächlichen Prozess ab, nicht den gewünschten. Erst wenn der Fluss sichtbar ist, werden Engpässe und Verschwendung erkennbar, und Verbesserungen setzen dort an. Für den Einstieg bietet flenio.ch eine Kanban-Board-Vorlage.
Wie sieht ein gutes Kanban-Board aus?
| Spalte | Bedeutung | WIP-Limit |
|---|---|---|
| Eingang | neue Anfragen, noch nicht geprüft | keins |
| Bereit | geprüft, priorisiert, kann begonnen werden | 8 |
| In Arbeit | wird erstellt | 5 |
| Interne Prüfung | Qualitätscheck im Team | 3 |
| Beim Kunden | wartet auf Freigabe des Kunden | 6 |
| Fertig | freigegeben und ausgeliefert | keins |
Das Board zeigt auf einen Blick, wo sich Arbeit staut. Häufen sich Einträge in der Spalte «Beim Kunden», liegt der Engpass bei den Freigaben, nicht im Team. Spalten für Wartezustände sind deshalb besonders wichtig: Sie machen sichtbar, wie viel Zeit Arbeit mit Warten verbringt, oft mehr als mit tatsächlicher Bearbeitung. Mehr zu Boards im Glossar unter Kanban-Board.
Wie legt man WIP-Limits fest?
WIP-Limits begrenzen die Anzahl der Einträge, die gleichzeitig in einer Spalte oder im gesamten Fluss sein dürfen. Sie sind der wichtigste Hebel von Kanban, weil zu viel gleichzeitige Arbeit zu ständigem Wechseln, langen Wartezeiten und späten Fertigstellungen führt. Eine einfache Startregel lautet: Zählen Sie, wie viele Einträge heute gleichzeitig in Arbeit sind, und setzen Sie das Limit etwas darunter. Alternativ beginnen viele Teams mit einem Limit von etwa der Zahl der Personen in der Spalte plus eins.
Ein WIP-Limit wirkt nur, wenn es eingehalten wird. Ist eine Spalte voll, wird kein neuer Eintrag begonnen; stattdessen hilft das Team, bestehende Einträge abzuschliessen. Dieser Grundsatz, erst fertigstellen, dann beginnen, ist anfangs ungewohnt, verkürzt aber die Durchlaufzeit spürbar. WIP-Limits sind Experimente: Sie werden beobachtet und angepasst, wenn sich zeigt, dass sie zu eng oder zu weit sind. Das Glossar erklärt den Begriff unter WIP-Limit.
Welche Flussmetriken sollten Sie messen?
| Metrik | Definition | Wozu sie dient |
|---|---|---|
| Work in Progress (WIP) | Anzahl begonnener, aber nicht abgeschlossener Einträge | Last im System sichtbar machen, Hebel für Verbesserung |
| Throughput (Durchsatz) | Anzahl abgeschlossener Einträge pro Zeiteinheit | Leistungsfähigkeit, Grundlage für Prognosen |
| Work Item Age | Zeit seit Beginn eines noch nicht abgeschlossenen Eintrags | frühes Warnsignal für hängende Arbeit |
| Cycle Time (Durchlaufzeit) | Zeit vom Beginn bis zum Abschluss eines Eintrags | Erwartungen an Lieferzeiten, Service-Level |
Der Kanban Guide nennt diese vier Metriken als Minimum [1]. Work Item Age ist dabei besonders nützlich im Alltag: Während die Cycle Time nur für abgeschlossene Einträge bekannt ist, zeigt das Alter laufender Einträge schon heute, welche Arbeit hängt. Ein Eintrag, der deutlich älter ist als die übliche Durchlaufzeit, verdient sofortige Aufmerksamkeit. Viele Teams leiten daraus eine Service-Level-Erwartung ab, etwa: Die meisten Einträge werden innerhalb von zehn Arbeitstagen fertig.
Was sagt Little's Law über WIP und Durchlaufzeit?
Little's Law ist ein Gesetz der Warteschlangentheorie und verbindet drei Grössen: Die durchschnittliche Durchlaufzeit entspricht der durchschnittlichen Anzahl laufender Einträge geteilt durch den durchschnittlichen Durchsatz. Daraus folgt eine für die Praxis zentrale Erkenntnis: Wer bei gleichem Durchsatz weniger gleichzeitig beginnt, verkürzt die Durchlaufzeit, ohne schneller arbeiten zu müssen.
| Situation | WIP (Einträge) | Durchsatz (pro Woche) | Durchlaufzeit (Wochen) |
|---|---|---|---|
| Ausgangslage | 12 | 3 | 4 |
| WIP halbiert, Durchsatz gleich | 6 | 3 | 2 |
| WIP halbiert, Durchsatz leicht höher durch weniger Wechsel | 6 | 3,5 | rund 1,7 |
Im Beispiel halbiert ein Team seine gleichzeitig laufende Arbeit von zwölf auf sechs Einträge. Bei gleichem Durchsatz von drei Einträgen pro Woche sinkt die durchschnittliche Durchlaufzeit von vier auf zwei Wochen. Oft steigt der Durchsatz zusätzlich leicht, weil weniger Wechsel zwischen Aufgaben nötig sind. Little's Law gilt für stabile Systeme im Durchschnitt; für einzelne Einträge ist die Verteilung der Durchlaufzeiten aussagekräftiger.
Kanban und Scrum kombinieren
Kanban und Scrum schliessen sich nicht aus. Viele Scrum Teams nutzen Kanban-Praktiken innerhalb ihrer Sprints: ein Board mit WIP-Limits, Flussmetriken im Daily Scrum und Durchsatz als Grundlage für das Sprint Planning. Der Scrum Guide nennt kumulative Flussdiagramme ausdrücklich als nützliche Praxis zur Prognose, betont aber, dass sie Empirie nicht ersetzen [3]. Die Kombination wird oft Scrumban genannt; mehr dazu auf der Seite Scrumban. Wie Metriken insgesamt sinnvoll genutzt werden, beschreibt der Beitrag Agile Metriken richtig nutzen.
Typische Fehler bei der Einführung von Kanban
| Fehler | Folge | Gegenmittel |
|---|---|---|
| Board ohne WIP-Limits | Board wird zur Aufgabenliste, Fluss verbessert sich nicht | Limits festlegen und einhalten |
| Wunschprozess statt tatsächlicher Prozess | Board stimmt nicht mit der Realität überein | mit dem heutigen Ablauf beginnen |
| Keine Wartespalten | Wartezeiten bleiben unsichtbar | Spalten für Warten und Blockiert einführen |
| Metriken nicht erhoben | Verbesserungen beruhen auf Gefühl | Start- und Enddaten automatisch erfassen |
| Keine regelmässige Verbesserung | Board bleibt statisch | wöchentlicher Blick auf Engpässe und alte Einträge |
Kanban im Werkzeug abbilden
Ein Kanban-Werkzeug sollte Spalten frei konfigurierbar machen, WIP-Limits anzeigen, Start- und Enddaten automatisch erfassen und daraus Auswertungen wie Durchlaufzeiten und Durchsatz erzeugen. In Flenio lassen sich Boards mit eigenen Spalten anlegen und Aufgaben mit Zeiterfassung verbinden. Wichtig ist, dass das Board der einzige Ort ist, an dem der Arbeitsstand gepflegt wird. Den Gesamtzusammenhang zeigt der Leitfaden Agiles Projektmanagement in der Praxis; die Methodenseite Kanban bietet einen ergänzenden Überblick.
Welche regelmässigen Termine braucht ein Kanban-Team?
Kanban schreibt keine Events vor, doch die meisten Teams etablieren einige regelmässige Termine. Ein tägliches kurzes Treffen am Board betrachtet den Fluss von rechts nach links: Was ist fast fertig, was blockiert, welche Einträge sind ungewöhnlich alt? Ein wöchentliches oder zweiwöchentliches Auffüllen klärt mit den Auftraggebern, welche Einträge als Nächstes in die Spalte Bereit kommen. Ein monatlicher Blick auf die Flussmetriken dient der Verbesserung, ähnlich einer Retrospektive.
Diese Termine sollten kurz und ergebnisorientiert sein. Der Unterschied zu Scrum liegt darin, dass sie nicht an feste Zyklen gebunden sind und nach Bedarf angepasst werden. Wer Anregungen für die Verbesserungsrunde sucht, findet Formate im Beitrag Retrospektive-Methoden.
Wie werden unterschiedlich dringende Aufträge behandelt?
Nicht alle Einträge sind gleich dringend. Viele Kanban-Teams unterscheiden deshalb Serviceklassen, etwa Standard, fester Termin und dringend. Dringende Einträge dürfen das WIP-Limit überschreiten, aber nur in begrenzter Zahl, etwa einer gleichzeitig. Einträge mit festem Termin werden rechtzeitig vorgezogen. So bleibt der Fluss für die meisten Einträge stabil, während echte Notfälle trotzdem Platz finden. Wichtig ist, die Regeln transparent zu machen, damit nicht jeder Auftrag zum Notfall erklärt wird.
Nach einigen Wochen mit Kanban zeigt sich typischerweise ein Muster: Die Zahl gleichzeitig laufender Einträge sinkt, die Durchlaufzeiten werden kürzer und gleichmässiger, und Engpässe werden sichtbar, die vorher im allgemeinen Stress untergingen. Diese Sichtbarkeit ist oft der wichtigste Gewinn, weil sie Gespräche über Prioritäten und Kapazitäten auf eine sachliche Grundlage stellt. Kanban wirkt damit oft zuerst als Werkzeug der Transparenz und erst danach als Werkzeug der Beschleunigung.