MethodenDeep-Dive

Kanban-Methode: Prinzipien, Praktiken und Grenzen erklärt

2. Oktober 2026 · Aktualisiert am 3. Oktober 2026 · Redaktion · 11 Min. Lesezeit

Kanban ist eine Methode, mit der ein Team seine Arbeit sichtbar macht, die Menge paralleler Aufgaben begrenzt und neue Arbeit erst dann beginnt, wenn Kapazität frei wird. Das Ziel ist ein gleichmäßiger Fluss: Aufgaben sollen schneller und berechenbarer fertig werden, nicht mehr Aufgaben gleichzeitig laufen.

Woher Kanban kommt und was das Wort bedeutet

Kanban stammt aus der Produktion von Toyota, wo Taiichi Ohno es ab 1947 als Teil des Toyota-Produktionssystems entwickelt hat. Das japanische Wort bedeutet „Schild“ oder „Kärtchen“: Eine Karte zeigte an, dass eine Station Nachschub braucht, und nur dann wurde produziert (Wikipedia: Kanban).

Für Wissensarbeit hat David J. Anderson die Idee Mitte der 2000er-Jahre übertragen, zuerst in Softwareteams. Daraus entstand die Kanban-Methode, die heute die Kanban University in ihrem Kanban Guide beschreibt. Daneben gibt es seit 2020 The Kanban Guide von Daniel Vacanti und John Coleman, eine bewusst knappe Fassung, die sich auf den Fluss konzentriert. Die aktuelle Fassung stammt vom Mai 2025.

Die Grundprinzipien von Kanban

Kanban beginnt mit dem, was ein Team heute tut. Das ist der erste von drei Grundsätzen für Veränderung im Kanban Guide der Kanban University: beim aktuellen Prozess anfangen, Verbesserung in kleinen, evolutionären Schritten anstreben und Führung auf allen Ebenen ermutigen.

Neben den drei Grundsätzen für Veränderung nennt der Kanban Guide der Kanban University drei Grundsätze für die Serviceerbringung: die Bedürfnisse und Erwartungen der Kunden verstehen; die Arbeit steuern und die Menschen sich selbst darum organisieren lassen; das Netz der Services und seine Regeln regelmäßig überprüfen. Eine Zählung mit vier Grundprinzipien enthält der aktuelle Guide nicht.

Der Unterschied zu anderen agilen Methoden liegt im Startpunkt. Wer Scrum einführt, übernimmt Rollen, Events und Sprints auf einmal. Wer Kanban einführt, ändert zunächst nichts an Rollen und Abläufen, sondern macht den bestehenden Workflow sichtbar und begrenzt ihn dann schrittweise.

Kanban verändert nicht zuerst die Organisation, sondern die Menge der gleichzeitig laufenden Arbeit — und daraus folgt der Rest.

Die sechs Kanban-Praktiken

Der Kanban Guide der Kanban University nennt sechs Praktiken: Arbeit visualisieren, Work in Progress begrenzen, den Fluss managen, Regeln explizit machen, Feedbackschleifen einrichten und gemeinsam experimentell verbessern. Die folgenden Abschnitte erklären jede Praktik mit ihrer Bedeutung im Alltag.

The Kanban Guide von Vacanti und Coleman fasst dasselbe kürzer: einen Workflow definieren, Aufgaben im Workflow aktiv steuern und den Workflow verbessern. Inhaltlich decken sich beide Fassungen weitgehend. Die Version der Kanban University ist umfangreicher, die von Vacanti und Coleman legt mehr Gewicht auf Kennzahlen.

Setzt ein Team die drei Praktiken aus The Kanban Guide um, heißt das Ergebnis dort Kanban-System. Zur Beschreibung des Workflows, im Guide Definition of Workflow genannt, gehört auch eine Service Level Expectation: eine Prognose, wie lange eine Aufgabe vom Start bis zur Fertigstellung brauchen sollte, zum Beispiel „85 Prozent der Aufgaben in acht Tagen oder weniger“. Sie stützt sich auf die bisher gemessenen Durchlaufzeiten.

Arbeit visualisieren: Spalten, Karten und Swimlanes

Ein Kanban-Board bildet jeden Schritt des Workflows als Spalte ab, jede Aufgabe als Karte. Die Karte wandert von links nach rechts, bis sie fertig ist. So sieht jeder im Team, was gerade läuft, was wartet und wo sich Arbeit staut.

Für den Start reichen drei Spalten: Offen, In Arbeit, Fertig. Mehr Spalten lohnen sich erst, wenn klar ist, an welcher Stelle Aufgaben tatsächlich liegen bleiben, etwa vor einem Review oder einer Freigabe. Wie du ein Board Schritt für Schritt aufbaust, zeigt die Anleitung zum Kanban-Board.

Swimlanes teilen das Board waagerecht in Bahnen, zum Beispiel nach Arbeitsart oder Dringlichkeit. Faustregel für Notfälle: eine eigene Bahn für dringende Aufgaben (Expedite) mit einem Limit von einer Karte. So werden Notfälle sichtbar, ohne den restlichen Fluss zu blockieren.

WIP-Limits und das Pull-Prinzip

Ein WIP-Limit legt fest, wie viele Karten höchstens gleichzeitig in einer Spalte oder einem Abschnitt des Boards liegen dürfen. WIP steht für Work in Progress, also begonnene, aber nicht fertige Arbeit. Ist das Limit erreicht, beginnt niemand eine neue Aufgabe, sondern hilft dabei, eine laufende abzuschließen.

Weder der Kanban Guide noch The Kanban Guide schreiben eine feste Zahl vor. Als Faustregel für den Start gilt Teamgröße plus eins für die Spalte „In Arbeit“. Wie du das WIP-Limit für dein Board festlegst und nach den ersten Wochen korrigierst, zeigt die Anleitung.

Beim Pull-Prinzip holt sich ein Teammitglied neue Arbeit erst dann, wenn es Kapazität hat. Arbeit wird also gezogen, nicht zugeteilt. Das unterscheidet Kanban von einem klassischen Aufgabenverteiler, bei dem jemand Aufgaben in die Liste anderer schiebt.

Gezogen wird von rechts nach links: Zuerst wird geprüft, ob sich eine Karte kurz vor dem Ziel abschließen lässt, erst danach wird neue Arbeit begonnen. In Kanban-Teams heißt der Leitsatz dafür: „Stop starting, start finishing.“ Er beschreibt den Kern des Pull-Prinzips in einem Satz.

Den Fluss managen: die vier Flow-Kennzahlen

Kanban misst nicht, wie beschäftigt ein Team ist, sondern wie gut Arbeit durch den Workflow fließt. The Kanban Guide nennt dafür vier Kennzahlen, die ein Team ohne Zusatzaufwand aus seinem Board ablesen kann.

Tabelle · seitlich schiebbar →

Die drei Größen Work in Progress, Durchsatz und Durchlaufzeit hängen über Littles Gesetz zusammen: Die durchschnittliche Durchlaufzeit entspricht dem durchschnittlichen Work in Progress geteilt durch den durchschnittlichen Durchsatz. Ein Team mit zwölf offenen Aufgaben, das sechs Aufgaben pro Woche fertigstellt, braucht im Schnitt zwei Wochen pro Aufgabe.

Der wichtigste Hebel von Kanban folgt aus Littles Gesetz: Wer die Durchlaufzeit senken will, muss nicht schneller arbeiten, sondern weniger gleichzeitig anfangen. Senkt ein Team mit sechs fertigen Aufgaben pro Woche seinen Work in Progress von zwölf auf sechs, sinkt die Durchlaufzeit rechnerisch von zwei Wochen auf eine.

Regeln explizit machen

Explizite Regeln legen fest, wann eine Karte in die nächste Spalte darf, wer neue Arbeit aufnimmt und wie mit blockierten Aufgaben umgegangen wird. Sie stehen sichtbar am Board, nicht im Kopf einzelner Personen. Bei Kanban heißen sie Policies. Wie ein Team dieselbe Idee auf seine ganze Zusammenarbeit überträgt, zeigt die Anleitung Teamregeln aufstellen.

Ein Beispiel für eine Policy: Eine Karte darf erst nach „Fertig“, wenn ein zweites Teammitglied sie geprüft hat. Solche Regeln verhindern Diskussionen darüber, was „fertig“ bedeutet, und machen Verbesserungen messbar, weil sich eine geänderte Regel mit der vorherigen vergleichen lässt.

Serviceklassen sind eine besondere Form von Policies. Sie regeln, dass manche Aufgaben anders behandelt werden, etwa dringende Aufgaben mit eigener Bahn oder Aufgaben mit festem Termin, die früher gestartet werden. David J. Anderson beschreibt dafür in seinem Buch „Kanban“ (2010) vier Klassen: dringend, fester Termin, Standard und immateriell, also Aufgaben ohne unmittelbaren Termindruck wie Aufräumarbeiten.

Feedbackschleifen bei Kanban

Feedbackschleifen sind regelmäßige Abstimmungen, in denen ein Team auf den Fluss schaut und Entscheidungen trifft. Die Kanban University nennt sie Kadenzen und beschreibt sieben davon, vom täglichen Kanban-Meeting bis zum Strategie-Review. Kein Team muss alle übernehmen.

Für den Einstieg reichen drei Kadenzen. Das tägliche Kanban-Meeting dauert als Faustregel 15 Minuten und geht das Board von rechts nach links durch. Das Replenishment entscheidet, welche Aufgaben als Nächstes ins Board kommen. Ein Service Delivery Review, etwa alle zwei Wochen, prüft die Kennzahlen.

Für die Rückschau auf die Zusammenarbeit eignet sich die Retrospektive, auch wenn sie aus Scrum stammt. Kanban-Teams setzen sie ohne festen Sprintrhythmus an, zum Beispiel einmal im Monat. Wie du eine Retro leitest, steht in der Anleitung zum Moderieren einer Retrospektive.

Gemeinsam verbessern

Die sechste Praktik verlangt, dass ein Team Änderungen am Workflow als Experiment behandelt: eine Hypothese aufstellen, eine Regel oder ein Limit ändern und anhand der Kennzahlen prüfen, ob es besser wurde. Ohne Messung ist eine Änderung bei Kanban nur eine Meinung.

Ein Beispiel: Das Team vermutet, dass Reviews der Engpass sind, etwa weil KI-Werkzeuge mehr Entwürfe liefern, als das Team prüfen kann. Es führt ein eigenes WIP-Limit für die Spalte „Review“ ein und vergleicht nach vier Wochen die Durchlaufzeit mit den vier Wochen davor. Faustregel: mindestens zwei bis vier Wochen messen, bevor du über ein Experiment entscheidest, sonst zählt der Zufall mehr als die Änderung.

Kanban im Alltag: ein typischer Ablauf

Ein Kanban-Team arbeitet ohne feste Zyklen, aber mit festen Gewohnheiten. Der Arbeitstag beginnt mit dem kurzen Treffen am Board: Was blockiert, was steht kurz vor dem Abschluss, wo kann jemand helfen? Wie solche Boards in Redaktion, Support und Personalabteilung aussehen, zeigen drei Kanban-Board-Beispiele.

Neue Aufgaben kommen nicht spontan ins Board, sondern über das Replenishment. Dort wählt das Team aus dem Backlog die nächsten Aufgaben aus und legt sie in die erste Spalte. Ist das Limit dort erreicht, bleibt der Rest im Backlog.

Im Lauf der Woche zieht jedes Teammitglied Arbeit nach, sobald es eine Aufgabe abgeschlossen hat. Blockierte Karten bekommen eine sichtbare Markierung und Vorrang im nächsten Treffen. Alle zwei bis vier Wochen schaut das Team auf die Kennzahlen und entscheidet, ob es ein Limit oder eine Regel ändert. Für gute Gesprächsführung in diesen Runden helfen Moderationstechniken.

Vorteile von Kanban

Kanban verkürzt die Durchlaufzeit, ohne dass jemand schneller arbeiten muss. Nach Littles Gesetz halbiert sich bei gleichem Durchsatz die durchschnittliche Durchlaufzeit, wenn ein Team seinen Work in Progress halbiert.

Kanban lässt sich mit geringem Aufwand einführen. Die Methode schreibt weder Rollen noch Meetings vor und startet mit dem Prozess, den ein Team schon hat. Faustregel für den Anfang: ein Board, ein WIP-Limit und ein kurzes tägliches Treffen.

Kanban macht Stau sichtbar, bevor er zum Termindruck wird. Dafür sorgt eine der vier Kennzahlen, die The Kanban Guide verlangt: das Alter laufender Aufgaben. Eine Karte, die deutlich länger offen ist als die übrigen, fällt im täglichen Treffen auf und bekommt Vorrang.

Kanban und Scrum im Vergleich

Kanban und Scrum schließen sich nicht aus, setzen aber an unterschiedlichen Stellen an. Scrum strukturiert Arbeit in Zeitboxen, Kanban begrenzt die Menge gleichzeitiger Arbeit.

Tabelle · seitlich schiebbar →

Die Angaben zu Scrum stammen aus dem Scrum Guide 2020. Faustregel für die Wahl: Kanban passt zu Teams mit schwer planbarem Zufluss, etwa Support, Betrieb oder Redaktion. Scrum passt zu Produktentwicklung, die von einem gemeinsamen Ziel pro Zyklus profitiert.

Scrumban: die Mischform aus Kanban und Scrum

Scrumban verbindet die Zeitboxen von Scrum mit den WIP-Limits und dem Pull-Prinzip von Kanban. Corey Ladas hat die Mischform 2008 in seinem Aufsatz „Scrumban“ beschrieben, als Weg für bestehende Scrum-Teams, ihren Ablauf schrittweise um Kanban-Elemente zu erweitern.

Mit der Zeit plant ein Scrumban-Team nicht mehr im festen Takt, sondern bei Bedarf: Sinkt die Zahl der bereitstehenden Aufgaben unter eine vereinbarte Marke, plant das Team nach. Ladas nennt diese Marke Bestellpunkt, nach dem Vorbild der Lagerhaltung. Faustregel: Scrumban lohnt sich für Scrum-Teams, deren Sprints regelmäßig von ungeplanter Arbeit unterbrochen werden.

Typische Fehler bei der Einführung von Kanban

Der folgenreichste Umsetzungsfehler bei Kanban ist ein Board ohne WIP-Limit. Es zeigt, was los ist, ändert aber nichts daran. Nach ein paar Wochen ist die Spalte „In Arbeit“ voll, und das Board wird zur Wandzeitung.

Ein zweiter Fehler sind zu große Karten. Eine Karte wie „Website neu bauen“ bleibt wochenlang in derselben Spalte und verfälscht jede Kennzahl. Faustregel: Eine Karte sollte sich in wenigen Tagen abschließen lassen.

Ein dritter Fehler ist ein Limit, das nie angepasst wird. Wer das Startlimit nach Monaten unverändert lässt, nutzt Kanban als Ritual, nicht als Werkzeug. Die Limits leben von der Beobachtung, die in den Feedbackschleifen stattfindet.

Ein vierter Fehler sind ungeklärte Blocker. Eine blockierte Karte zählt weiter gegen das Limit. Wenn niemand sich darum kümmert, blockiert sie den ganzen Fluss, und das Team weicht auf neue Arbeit aus, die es eigentlich nicht beginnen dürfte.

Grenzen und Nachteile von Kanban

Kanban liefert keine festen Zusagen pro Zeitraum. Wer Stakeholdern sagen muss, was bis zu einem Stichtag fertig ist, braucht dafür Flow-Daten aus mehreren Wochen. Ein neues Kanban-Team kann solche Prognosen am Anfang nicht seriös abgeben.

Kanban löst keine Prioritätenprobleme. Wenn unklar ist, was wichtig ist, macht das Board den Konflikt nur sichtbar. Die Entscheidung, was ins Replenishment kommt, muss jemand treffen, und Kanban schreibt nicht vor, wer das ist — das regeln die Entscheidungsrechte im Team.

Kanban braucht eine gewisse Menge an Arbeit. Ein Team, das im Monat drei große Aufgaben abschließt, hat zu wenige Datenpunkte für aussagekräftige Kennzahlen. Für solche Teams bringt das Board Übersicht, die Flow-Steuerung aber wenig.

Kanban fehlt ein gemeinsamer Takt für Ziele. Teams, die ein übergreifendes Ziel brauchen, um sich auszurichten, vermissen bei Kanban den Sprint als gemeinsamen Fixpunkt. Hier lohnt der Blick auf Scrum oder auf Scrumban, eine Mischform, die Sprints mit WIP-Limits kombiniert. Ein gemeinsames Ziel für das Quartal kann ein Kanban-Team auch mit OKR setzen, ohne den Fluss auf dem Board zu ändern.

Und Kanban lebt von Disziplin. Ein Limit wirkt nur, wenn das Team es einhält, auch wenn ein dringender Wunsch von außen kommt. Wo das Umfeld Limits nicht respektiert, braucht es zuerst Rückhalt von der Führung, etwa über einen Agile Coach, der die Einführung begleitet.

Fragen und Antworten

Quellen

1. Kanban Guide (Kanban University) (abgerufen am 3. Oktober 2026)
2. The Kanban Guide (Vacanti, Coleman) (abgerufen am 3. Oktober 2026)
3. A Proof for the Queuing Formula: L = λW (John D. C. Little, 1961) (abgerufen am 3. Oktober 2026)
4. Scrum Guide 2020 (abgerufen am 3. Oktober 2026)
5. Kanban (Wikipedia) (abgerufen am 3. Oktober 2026)
6. Scrumban (Corey Ladas, Agile Alliance) (abgerufen am 3. Oktober 2026)