Was ist Kanban?
Kanban ist eine agile Methode zur Visualisierung und Optimierung von Arbeitsflüssen. Der Name stammt aus dem Japanischen und bedeutet wörtlich "Signalkarte" oder "visuelles Signal". Das Grundprinzip: Mache die Arbeit sichtbar, begrenze die Menge gleichzeitig bearbeiteter Aufgaben und verbessere den Fluss kontinuierlich.
Kanban wurde in den 1940er Jahren bei Toyota als System zur Produktionssteuerung entwickelt. Taiichi Ohno, ein Ingenieur bei Toyota, ließ sich vom Nachschub-System amerikanischer Supermärkte inspirieren: Produkte werden erst nachgefüllt, wenn der Bestand eine bestimmte Schwelle unterschreitet. Dieses Pull-Prinzip -- Arbeit wird gezogen, nicht geschoben -- ist das Herzstück von Kanban.
David J. Anderson adaptierte das Toyota-System 2007 für die Wissensarbeit und formulierte die Kanban-Methode für Software-Entwicklung und Projektmanagement. Heute wird Kanban weltweit in IT-Teams, Marketing-Abteilungen, HR, Support und vielen anderen Bereichen eingesetzt.
Anders als Scrum, das neue Rollen und Events einführt, startet Kanban dort, wo das Team heute steht. Es werden keine bestehenden Prozesse, Rollen oder Titel geändert. Stattdessen wird der aktuelle Workflow visualisiert und schrittweise verbessert. Das macht Kanban besonders geeignet für Teams, die keine radikale Umstellung wollen.
Die 4 Kanban Prinzipien
1. Starte mit dem, was du jetzt tust
Kanban erfordert keine Revolution. Du beginnst mit deinem aktuellen Prozess, visualisierst ihn auf einem Board und verbesserst ihn schrittweise. Es gibt keinen "Tag 1", an dem alles anders ist -- Kanban ist ein sanfter Einstieg in die Prozessverbesserung.
2. Verfolge inkrementelle, evolutionäre Veränderung
Große Veränderungen erzeugen Widerstand. Kanban setzt auf kleine, kontinuierliche Verbesserungen (Kaizen). Das Team identifiziert Engpässe, experimentiert mit Lösungen und passt den Prozess schrittweise an -- ohne das gesamte System auf einmal umzubauen.
3. Respektiere bestehende Rollen und Verantwortlichkeiten
Kanban definiert keine neuen Rollen. Der Teamleiter bleibt Teamleiter, der Entwickler bleibt Entwickler. Die bestehende Organisationsstruktur wird respektiert. Veränderungen in Rollen können sich aus der Praxis ergeben, werden aber nicht von Kanban vorgeschrieben.
4. Fördere Führung auf allen Ebenen
Verbesserungen sollen nicht nur "von oben" kommen. Jedes Teammitglied ist eingeladen, Engpässe zu erkennen, Verbesserungen vorzuschlagen und Verantwortung für den Arbeitsprozess zu übernehmen. Kanban fördert eine Kultur, in der Führung eine Aktivität ist, kein Titel.
Das Kanban-Board im Überblick
Aufgaben fließen von links nach rechts durch definierte Phasen — mit WIP-Limits zur Vermeidung von Überlastung.
Kanban-Board mit vier Spalten und WIP-Limits. Tasks fließen nach dem Pull-Prinzip von links nach rechts.
Die 6 Kanban Praktiken
1. Visualisiere den Arbeitsfluss
Die wichtigste Praktik: Mache die gesamte Arbeit sichtbar. Ein Kanban Board zeigt alle Aufgaben, ihren aktuellen Status und den Fluss durch den Prozess. Wenn Arbeit unsichtbar ist, kann sie nicht gemanagt werden. Das Board ist kein Planungstool -- es ist ein Spiegel des realen Arbeitsprozesses.
2. Limitiere die Arbeit in Bearbeitung (WIP-Limits)
WIP-Limits (Work in Progress) begrenzen, wie viele Aufgaben gleichzeitig in einer Spalte sein dürfen. Warum? Weil Multitasking die Durchlaufzeit verlängert und die Qualität senkt. Wenn ein WIP-Limit erreicht ist, darf keine neue Aufgabe begonnen werden, bis eine bestehende abgeschlossen oder weitergegeben wurde. Das zwingt das Team, Arbeit fertigzustellen statt neue anzufangen.
3. Manage den Fluss
Das Ziel ist ein gleichmäßiger, vorhersagbarer Arbeitsdurchsatz. Das Team beobachtet, wie schnell Aufgaben durch das System fließen (Durchlaufzeit, Throughput), und optimiert den Fluss. Stau in einer Spalte deutet auf einen Engpass hin -- dort muss angesetzt werden.
4. Mache Prozessregeln explizit
Wann ist eine Aufgabe "fertig"? Wer darf Aufgaben in welche Spalte verschieben? Was sind die Kriterien für Priorisierung? Diese Regeln sollten schriftlich festgehalten und für alle sichtbar sein -- am besten direkt am Board.
5. Implementiere Feedback-Schleifen
Regelmäßige Meetings sorgen für Transparenz und Anpassung. Die wichtigsten Kanban-Meetings: tägliches Stand-up am Board (15 Minuten), wöchentliches Replenishment Meeting (neue Aufgaben priorisieren) und monatliche Service Delivery Review (Durchsatz und Durchlaufzeit analysieren).
6. Verbessere kollaborativ, entwickle experimentell
Verbesserungen basieren auf Daten und Experimenten, nicht auf Meinungen. Das Team formuliert Hypothesen ("Wenn wir das WIP-Limit von 6 auf 4 senken, sinkt die Durchlaufzeit"), testet sie und evaluiert die Ergebnisse. Dieser wissenschaftliche Ansatz verhindert endlose Diskussionen und führt zu messbaren Verbesserungen.
Kanban Board aufbauen: Spalten, Swimlanes und WIP-Limits
Ein Kanban Board ist die visuelle Darstellung deines Arbeitsprozesses. Jede Spalte repräsentiert einen Status, jede Karte eine Aufgabe. Das Board kann physisch (Whiteboard mit Post-its) oder digital (Tools wie Trello, Jira, PathHub AI) sein.
Beispiel-Board: Software-Team
Feature
Aufgabe
Bug
Feature
Aufgabe
Feature
Feature
Bug
Spalten gestalten
Die Spalten des Boards bilden die Stationen deines Arbeitsprozesses ab. Ein typisches Software-Board könnte so aussehen: Backlog, Analyse, Entwicklung, Code Review, Testing, Fertig. Wichtig: Bilde deinen tatsächlichen Prozess ab, nicht einen idealisierten. Spalten können auch zweigeteilt werden ("Entwicklung: In Arbeit" und "Entwicklung: Wartend auf Review").
Swimlanes einsetzen
Swimlanes sind horizontale Bahnen, die das Board in Bereiche unterteilen. Typische Anwendungen: Swimlanes nach Priorität (Expedite, Standard, Wartend), nach Aufgabentyp (Feature, Bug, Technische Schulden) oder nach Team/Person. Swimlanes helfen, verschiedene Arbeitskategorien auf einem Board zu managen.
WIP-Limits richtig setzen
Das WIP-Limit ist das mächtigste Werkzeug in Kanban -- und gleichzeitig das am häufigsten falsch eingesetzte. Zu hoch gesetzt, verliert es seine Wirkung. Zu niedrig, und das Team sitzt im Leerlauf. Die Kunst liegt im richtigen Gleichgewicht.
WIP-Limit = Anzahl Teammitglieder × 1,5 (aufgerundet)
Beispiele:
- 3 Personen im Team: WIP-Limit = 5
- 5 Personen im Team: WIP-Limit = 8
- 8 Personen im Team: WIP-Limit = 12
Das ist ein Startpunkt, kein Gesetz. Beobachte den Flow über 2-3 Wochen und passe an: Staut sich Arbeit regelmäßig? Limit senken. Haben Leute häufig nichts zu tun? Limit leicht erhöhen.
WIP-Limits pro Spalte
Das Gesamt-WIP-Limit wird auf die einzelnen Spalten verteilt. Ein Team mit 5 Personen und einem Gesamt-WIP von 8 könnte die Limits so verteilen:
- To Do (Ready): WIP-Limit 5 -- genug Aufgaben als Puffer, damit niemand warten muss.
- In Progress: WIP-Limit 5 -- maximal eine Aufgabe pro Person als Hauptaufgabe.
- Review: WIP-Limit 3 -- Reviews sollen schnell erledigt werden, damit der Flow nicht stockt.
Wichtig: Das WIP-Limit der Review-Spalte ist oft der kritischste Punkt. Wenn Reviews sich stauen, blockiert das den gesamten Fluss. Viele Teams machen die Regel: "Review hat Vorrang vor neuer Arbeit" -- das beschleunigt den Durchsatz erheblich.
📋 Interaktives Kanban-Board
Erstelle dein eigenes Kanban-Board: Füge Aufgaben hinzu und verschiebe sie zwischen den Spalten.
0 Aufgaben
Kanban vs. Scrum: Die wichtigsten Unterschiede
| Kriterium | Kanban | Scrum |
|---|---|---|
| Takt | Kontinuierlicher Fluss | Feste Sprints (1-4 Wochen) |
| Rollen | Keine vorgeschriebenen Rollen | Product Owner, Scrum Master, Developers |
| Planung | Laufend, nach Kapazität (Pull) | Sprint-weise im Sprint Planning |
| Änderungen | Jederzeit möglich (neue Karten ins Backlog) | Zwischen Sprints (nicht während eines Sprints) |
| Limitierung | WIP-Limits pro Spalte | Sprint-Umfang (Velocity-basiert) |
| Metriken | Durchlaufzeit, Throughput, Cumulative Flow | Velocity, Sprint Burndown, Burnup |
| Meetings | Keine vorgeschriebenen (empfohlen: Stand-up) | 5 definierte Events (Sprint, Planning, etc.) |
| Einführung | Evolutionär (bestehende Prozesse beibehalten) | Revolutionär (neue Rollen und Events einführen) |
| Geeignet für | Support, Wartung, Operations, Service-Teams | Produktentwicklung, komplexe Projekte |
In der Praxis nutzen viele Teams einen Hybridansatz, oft "Scrumban" genannt: Sie verwenden ein Kanban Board mit WIP-Limits, arbeiten aber in festen Iterationen wie bei Scrum. Das kann das Beste beider Welten vereinen, erfordert aber Disziplin, um nicht die Vorteile beider Methoden zu verwässern.
Kanban-Metriken: Lead Time, Cycle Time, Throughput
Was du nicht misst, kannst du nicht verbessern. Kanban definiert drei Kernmetriken, die dir zeigen, wie effizient dein System arbeitet.
Lead Time
Die Lead Time misst die Gesamtdauer von dem Moment, in dem eine Aufgabe ins System kommt (Backlog), bis sie fertig ist (Done). Sie repräsentiert die Kundenperspektive: Wie lange muss der Auftraggeber warten, bis seine Anfrage erledigt ist?
Beispiel: Ein Feature-Request wird am Montag erstellt und am folgenden Mittwoch ausgeliefert. Die Lead Time beträgt 9 Tage. Ziel ist es, die Lead Time zu senken und ihre Streuung (Varianz) zu reduzieren -- das macht die Lieferzeiten vorhersagbar.
Cycle Time
Die Cycle Time misst nur die aktive Bearbeitungszeit -- also ab dem Moment, in dem jemand die Aufgabe in "In Progress" zieht, bis sie "Done" ist. Die Differenz zwischen Lead Time und Cycle Time zeigt dir die Wartezeit im System. Eine hohe Wartezeit deutet auf Engpässe im Backlog-Management oder in der Priorisierung hin.
Throughput
Der Throughput gibt an, wie viele Aufgaben pro Zeiteinheit (Tag, Woche, Monat) abgeschlossen werden. Er ist die wichtigste Metrik für die Kapazitätsplanung. Wenn dein Team durchschnittlich 12 Aufgaben pro Woche abschließt und im Backlog 36 Aufgaben liegen, weißt du: Du brauchst ungefähr 3 Wochen.
Kanban-Metriken dienen der Prozessverbesserung, nicht der Leistungsbeurteilung einzelner Personen. Nutze sie, um Engpässe zu finden und Experimente zu starten -- nicht, um Druck auf einzelne Teammitglieder auszuüben. Ein Team, das seine Metriken fürchtet, wird aufhören, sie ehrlich zu messen.
Häufige Kanban-Fehler
Kanban klingt einfach -- und genau das ist die Falle. Viele Teams setzen ein Board auf, ignorieren aber die entscheidenden Prinzipien. Hier sind die fünf häufigsten Fehler:
- 1. Kein WIP-Limit setzen: Ein Board ohne WIP-Limit ist kein Kanban-Board -- es ist eine To-Do-Liste mit Spalten. Ohne Begrenzung der laufenden Arbeit entstehen Engpässe, Multitasking und Überlastung. Das WIP-Limit ist nicht optional, es ist das Kernprinzip.
- 2. WIP-Limit nicht durchsetzen: Noch schlimmer als kein Limit ist ein Limit, das regelmäßig überschritten wird. "Ausnahmen" für dringende Aufgaben untergraben das gesamte System. Nutze stattdessen eine Expedite-Lane mit eigenem, sehr niedrigem WIP-Limit (z. B. 1).
- 3. Das Board nicht aktuell halten: Wenn Karten nicht bewegt werden und der Status nicht stimmt, verliert das Board seinen Wert als Steuerungsinstrument. Regel: Jede Statusänderung wird sofort auf dem Board abgebildet -- nicht erst im nächsten Standup.
- 4. Keine Metriken messen: Ohne Lead Time, Cycle Time und Throughput fliegst du blind. Du merkst nicht, ob Verbesserungen wirken oder ob die Performance stagniert. Schon einfaches Tracking (wann wurde die Karte erstellt, wann abgeschlossen?) reicht für den Anfang.
- 5. Kanban als reine Visualisierung verstehen: Ein Board aufzuhängen macht dich nicht agil. Kanban ist ein System der kontinuierlichen Verbesserung. Wenn du nie Feedback-Schleifen durchführst, nie WIP-Limits anpasst und nie Engpässe analysierst, nutzt du nur 10 % des Potenzials.
Kanban-Board-Beispiele für verschiedene Teams
Kanban ist keine One-Size-Fits-All-Lösung. Die Spaltenstruktur und die Regeln müssen zum Arbeitsprozess des Teams passen. Hier sind drei bewährte Board-Setups:
Software-Entwicklungsteam
Ein typisches Kanban-Board für ein Entwicklerteam mit 5 Personen:
- Backlog (kein Limit) -- User Stories, Bugs, technische Schulden, priorisiert durch den Product Owner.
- Ready for Dev (WIP: 4) -- Stories mit Akzeptanzkriterien, geschätzt und bereit zur Umsetzung.
- In Development (WIP: 5) -- Aktive Entwicklung. Jeder Entwickler hat maximal eine Story.
- Code Review (WIP: 3) -- Pull Requests warten auf Review. Regel: Reviews innerhalb von 4 Stunden.
- QA / Testing (WIP: 3) -- Funktionale Tests, Regressionstests, Abnahme.
- Done -- Deployed und abgenommen.
Swimlanes: Obere Lane für Hotfixes (Expedite, WIP: 1), mittlere Lane für Features, untere Lane für technische Schulden.
Marketing-Team
Ein Content-Marketing-Team mit 4 Personen:
- Ideen / Backlog (kein Limit) -- Content-Ideen aus Brainstormings, SEO-Recherche, Kundenanfragen.
- Briefing (WIP: 3) -- Thema ist definiert, Zielgruppe, Keywords und Format stehen fest.
- In Produktion (WIP: 4) -- Text wird geschrieben, Design wird erstellt, Video wird produziert.
- Review & Freigabe (WIP: 2) -- Lektorat, Markencheck, rechtliche Freigabe.
- Geplant (WIP: 3) -- Content ist fertig und für Veröffentlichung eingeplant.
- Veröffentlicht -- Live und im Monitoring.
Swimlanes: Nach Content-Typ (Blog, Social Media, Newsletter) oder nach Kampagne.
HR / People Operations
Ein HR-Team, das Recruiting-Prozesse mit Kanban steuert:
- Offene Stellen (kein Limit) -- Genehmigte Stellenausschreibungen.
- Sourcing (WIP: 5) -- Aktive Suche und Ansprache von Kandidaten.
- Screening (WIP: 4) -- Bewerbungsunterlagen werden gesichtet, Erstgespräch wird geführt.
- Interview (WIP: 3) -- Fachgespräch, Probeaufgabe, Teamgespräch.
- Angebot (WIP: 2) -- Vertragsverhandlung, Gehaltsabstimmung.
- Eingestellt -- Vertrag unterschrieben, Onboarding geplant.
Swimlanes: Nach Abteilung (Entwicklung, Vertrieb, Marketing) oder nach Seniorität (Junior, Mid, Senior).
Kanban für Projekte: Wann ist es die richtige Wahl?
Kanban ist besonders geeignet, wenn folgende Bedingungen zutreffen:
- Kontinuierlicher Aufgabenstrom: Dein Team bearbeitet laufend eingehende Anfragen, Tickets oder Aufgaben -- nicht gebündelt in Releases oder Sprints.
- Unterschiedliche Aufgabentypen: Features, Bugs, Support-Anfragen und technische Schulden landen im gleichen Team. Kanban erlaubt Priorisierung ohne starre Sprint-Grenzen.
- Bestehende Prozesse optimieren: Das Team funktioniert grundsätzlich, aber der Durchsatz soll verbessert und Engpässe beseitigt werden.
- Widerstand gegen große Veränderungen: Wenn die Organisation nicht bereit ist für neue Rollen (Scrum Master, Product Owner), bietet Kanban einen sanfteren Einstieg.
- Service-orientierte Teams: IT-Support, DevOps, Wartungsteams und Kundensupport profitieren besonders von der Kanban-Methode.
Kanban ist weniger geeignet, wenn du ein neues Produkt entwickelst und regelmäßige, planbare Releases brauchst. In diesem Fall ist Scrum oft die bessere Wahl. Für Projekte mit klar definiertem Scope und regulatorischen Anforderungen kann ein klassischer Projektplan sinnvoller sein.
Digitale Kanban-Tools
Ein physisches Board an der Wand hat seinen Charme -- aber für verteilte Teams und langfristige Nachverfolgung führt kein Weg an digitalen Tools vorbei. Die gängigen Kanban-Tools 2026:
- Trello: Der Klassiker für einfache Kanban-Boards. Intuitiv, kostenlos für kleine Teams, begrenzte Automatisierung.
- Jira: Der Standard in der Softwareentwicklung. Mächtig, aber mit steiler Lernkurve. Kanban- und Scrum-Boards, umfangreiche Metriken.
- Asana: Board-Ansicht für Kanban, zusätzlich Listen und Timeline. Gut für Nicht-Entwicklerteams.
- Monday.com: Flexibel anpassbar, gute Visualisierungen, aber schnell teuer bei größeren Teams.
- Notion: Datenbank-basierte Boards, die sich für Kanban nutzen lassen. Flexible, aber kein dediziertes Kanban-Tool.
Aber: Kanban-Tools steuern die Ausführung -- sie helfen dir nicht bei der Planung. Bevor du dein Board mit Aufgaben füllst, brauchst du einen strukturierten Projektplan. Und genau hier setzt PathHub AI an.
PathHub AI generiert in Sekunden einen strukturierten Projektplan mit Phasen, Aufgaben und Meilensteinen. Die KI identifiziert automatisch Stakeholder, erkennt Risiken und schlägt realistische Zeitrahmen vor. Die generierten Aufgaben lassen sich direkt als Kanban-Karten in dein Board übertragen. So startest du nicht mit einem leeren Board, sondern mit einem durchdachten Plan.
Kanban zeigt den Status -- PathHub AI plant das Projekt.
Kanban und KI: Wie PathHub AI agile Planung unterstützt
Auch wenn Kanban auf einen kontinuierlichen Fluss setzt, braucht jedes Projekt eine übergeordnete Planung: Welche Aufgaben gibt es? Wie hängen sie zusammen? Was ist der Zeitrahmen? Was ist das Budget? Genau hier unterstützt PathHub AI.
- Aufgaben generieren: Beschreibe dein Projekt, und PathHub AI erstellt eine strukturierte Aufgabenliste -- die perfekte Grundlage für das Kanban Backlog.
- Phasen als Swimlanes: Die KI-generierten Projektphasen können als Swimlanes auf dem Kanban Board dienen, um verschiedene Arbeitsbereiche zu trennen.
- Zeitschätzung und Priorisierung: Die KI schätzt Dauer und Aufwand pro Aufgabe -- hilfreiche Informationen für die Priorisierung und das Kapazitätsmanagement.
- Budget und Ressourcen: PathHub AI liefert Budgetschätzungen pro Phase, die als Orientierung für die Ressourcenplanung dienen.