Kanban: Arbeit sichtbar machen und begrenzen

Kanban: Arbeit sichtbar machen und begrenzen

https://bildung.social/@oerinformatik/

https://oer-informatik.de/kanban

Kanban, Vorgehensmodelle, Kanban-Board, WIP-Limit, Pull-Prinzip, Durchlaufzeit, Durchsatz, Cumulative Flow Diagram, Littles Gesetz, Lean, agile Softwareentwicklung

tl/dr; (ca. 14 min Lesezeit): Kanban steuert Arbeit über ihren Fluss: Alle Aufgaben stehen sichtbar auf einem Board, ein WIP-Limit begrenzt die gleichzeitig laufende Arbeit, und wer frei ist, zieht sich die nächste Karte. Sprints und feste Rollen gibt es nicht. Der Artikel erklärt Herkunft, Prinzipien und Praktiken von Kanban, das Board mit WIP-Limits, die Flusskennzahlen Durchlaufzeit, Durchsatz, WIP und Alter einer Karte, das Cumulative Flow Diagram und die Abgrenzung zu Scrum [AI-Assisted]. (Zuletzt geändert am 30.10.2026)

Disclaimer: Teile des Textes stammen von einer KI. Inhalte sind nicht automatisch zuverlässig; überprüfe Fakten und zitiere vertrauenswürdige Quellen.

Dieser Artikel ist Teil einer Artikelreihe über Vorgehensmodelle: Überblick: klassisch und agil / Wasserfallmodell / V-Modell / Spiralmodell / Scrum / Extreme Programming / Kanban / SAFe / DevOps / Übungsaufgaben

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

In einem Satz: Kanban zeichnet sich dadurch aus, dass der Arbeitsfluss auf einem Board sichtbar gemacht, die gleichzeitig laufende Arbeit begrenzt und der Fluss anhand von Kennzahlen laufend verbessert wird – ohne feste Iterationen und ohne vorgegebene Rollen.

Das wichtigste Werkzeug ist das Kanban-Board: Jede Spalte steht für einen Arbeitsschritt, jede Karte für eine Aufgabe, und WIP-Limits legen fest, wie viele Karten höchstens in einer Spalte liegen dürfen.

Herkunft: von Toyota in die Wissensarbeit

Kanban (japanisch etwa „Signalkarte“) stammt aus der Produktion: Bei Toyota entwickelte Taiichi Ohno ab den 1950er Jahren ein Kartensystem, mit dem eine Station Material erst dann nachbestellt, wenn sie es wirklich braucht (Just in Time, Pull-Prinzip). In der Softwareentwicklung und anderer Wissensarbeit wurde Kanban ab etwa 2004 vor allem durch David J. Anderson bekannt, der es u. a. bei Microsoft einsetzte; sein Buch „Kanban: Successful Evolutionary Change for Your Technology Business“ (2010) beschreibt die Kanban-Methode. Daneben gibt es den kompakten Kanban Guide von Daniel Vacanti und John Coleman (2020, aktuelle Fassung von Mai 2025). Ziel ist, Arbeit vorhersehbarer und schneller fertigzustellen, indem Engpässe sichtbar und Wartezeiten kleiner werden. Typische Einsatzbereiche sind fortlaufende Arbeit mit unvorhersehbarem Eingang wie Support, Wartung, Betrieb oder Redaktionsarbeit.

Grundprinzipien: Fluss statt Takt

Die Kanban-Methode nach Anderson beginnt mit drei Grundsätzen für Veränderung:

• Beginne mit dem, was Du jetzt tust: Kanban ersetzt keinen bestehenden Ablauf, sondern macht ihn sichtbar.

• Verfolge evolutionäre Veränderung: kleine, gemeinsam vereinbarte Verbesserungsschritte statt großer Umstellung.

• Fördere Führung auf allen Ebenen: Verbesserungen können von jeder Person ausgehen.

Daraus ergeben sich die Kernpraktiken der Kanban-Methode, hier ergänzt um das Pull-Prinzip, das aus den WIP-Limits folgt:

• Visualisieren: Alle Aufgaben stehen als Karten auf einem Kanban-Board mit Spalten wie „Offen – In Arbeit – Test – Erledigt“.

• Laufende Arbeit begrenzen (WIP-Limit, work in progress): Jede Spalte darf nur eine bestimmte Zahl von Karten enthalten. So wird erst fertiggestellt, bevor Neues begonnen wird („Stop starting, start finishing“).

• Pull-Prinzip: Wer frei ist, zieht sich die nächste Karte, statt dass Arbeit zugeteilt wird – aber nur, wenn das WIP-Limit der Zielspalte es zulässt.

• Fluss managen und messen: z. B. die Durchlaufzeit einer Karte vom Start bis „Erledigt“.

• Regeln explizit machen: Wann darf eine Karte weiter? Was heißt „fertig“?

• Feedback-Schleifen einrichten und gemeinsam verbessern.

Besonders an Kanban ist, dass es keine Iterationen, keine festen Rollen und keine vorgeschriebenen Artefakte gibt. Es ist weniger ein Vorgehensmodell im engen Sinn als eine Methode, einen vorhandenen Ablauf zu steuern und zu verbessern.

Ablauf: eine Karte auf ihrem Weg

Statt Phasen oder Sprints gibt es einen kontinuierlichen Fluss: Neue Aufgaben kommen jederzeit ins Backlog, die wichtigste wird gezogen, sobald Kapazität frei ist, und wandert Spalte für Spalte nach rechts. Ist eine Folgespalte voll, wird nicht Neues begonnen, sondern beim Engpass geholfen. Das Aktivitätsdiagramm zeigt den Weg einer Karte:

Kanban schreibt keine Meetings vor, empfiehlt aber regelmäßige Termine (Kadenzen). Verbreitet sind ein tägliches kurzes Kanban-Meeting am Board (Was hängt? Wo staut es sich?), ein Replenishment-Meeting, in dem das Backlog aufgefüllt und priorisiert wird, und regelmäßige Reviews des Flusses und der Servicequalität. Ausgeliefert wird, sobald eine Aufgabe fertig ist, oder in vereinbarten Abständen.

Rollen: keine Pflichtrollen

Kanban kennt keine vorgeschriebenen Rollen; vorhandene Rollen bleiben zunächst bestehen („Beginne mit dem, was Du jetzt tust“). Anderson schlägt zwei optionale Rollen vor: den Service Request Manager, der die Anforderungen der Kundschaft versteht und den Eingang ordnet (ähnlich einem Product Owner), und den Service Delivery Manager, der den Fluss im Blick behält und Hindernisse beseitigt (ähnlich einem Scrum Master oder Teamcoach). Die Zusammenarbeit ist von Selbstorganisation und Transparenz geprägt: Das Board zeigt allen, woran gerade gearbeitet wird und wo Hilfe nötig ist.

Artefakte: Board, Karten, Regeln

Die Dokumentation ist leichtgewichtig: Was über Board, Karten und Regeln hinaus dokumentiert wird, entscheidet das Team bzw. der bestehende Prozess.

Qualität und Test: Qualität als Spalte und Regel

Kanban schreibt keine Teststrategie vor. Qualität wird über den Workflow gesichert: Test, Review oder Abnahme sind eigene Spalten mit eigenem WIP-Limit, und die expliziten Regeln legen fest, welche Kriterien eine Karte erfüllen muss, um weiterzuwandern (ähnlich einer Definition of Done je Spalte). Weil WIP-Limits Staus sichtbar machen, fällt ein Engpass beim Testen sofort auf; das Team hilft dort, statt weitere ungetestete Arbeit anzuhäufen. Technische Praktiken wie automatisierte Tests oder kontinuierliche Integration werden oft ergänzt.

Stakeholder: Serviceziele und kurze Wege

Stakeholder geben Aufgaben über das Backlog ein und sehen den Stand jederzeit am Board. Im Replenishment-Meeting entscheiden sie mit, was als Nächstes gezogen wird; in Service-Reviews wird besprochen, ob Durchlaufzeiten und Serviceziele (z. B. „85 % der Störungen innerhalb von zwei Tagen gelöst“) eingehalten werden. Weil Aufgaben ausgeliefert werden können, sobald sie fertig sind, kommen Ergebnisse oft schneller an als bei festen Sprints.

Planung und Kontrolle: Flusskennzahlen

Kanban plant nicht über Schätzungen, sondern über gemessene Flussdaten. Der Kanban Guide nennt vier Kennzahlen:

• Work in Progress (WIP): Zahl der begonnenen, aber nicht fertigen Karten,

• Durchsatz (Throughput): Zahl der fertigen Karten pro Zeiteinheit,

• Durchlaufzeit (Cycle Time): Zeit vom Start bis zur Fertigstellung einer Karte,

• Alter einer Karte (Work Item Age): wie lange eine laufende Karte schon in Arbeit ist.

Den Zusammenhang beschreibt Littles Gesetz: durchschnittliche Durchlaufzeit = durchschnittlicher WIP / durchschnittlicher Durchsatz. Wer den WIP senkt, verkürzt bei gleichem Durchsatz die Durchlaufzeit. Prognosen („Wann sind diese 20 Karten fertig?“) entstehen aus den gemessenen Werten, oft mit Monte-Carlo-Simulationen. Ein wichtiges Werkzeug ist das Cumulative Flow Diagram (CFD): Es zeigt je Tag, wie viele Karten welche Spalte schon erreicht haben. Der senkrechte Abstand zwischen zwei Linien ist der WIP, der waagerechte Abstand die ungefähre Durchlaufzeit; wird ein Band breiter, staut sich dort die Arbeit.

Skalierung und Anpassbarkeit: vom Team zum Portfolio

Kanban lässt sich gut anpassen, weil es auf dem vorhandenen Ablauf aufbaut. Für größere Organisationen gibt es Portfolio-Kanban (Boards für Projekte oder Epics statt Aufgaben) und das Modell der Flight Levels (Klaus Leopold), das Boards auf Team-, Koordinations- und Strategieebene verbindet. Häufige Anpassungen sind Schwimmbahnen für dringende Aufgaben (Expedite), Serviceklassen mit unterschiedlichen Zielen und die Kombination mit Scrum (Scrumban oder der Kanban Guide for Scrum Teams).

Häufig genutzte Techniken

• Durchlaufzeit-Streudiagramm und Monte-Carlo-Prognosen,

• Serviceklassen (z. B. Standard, feste Frist, dringend),

• Engpassanalyse und Wertstromanalyse aus dem Lean Management,

• digitale Boards in Ticketsystemen,

• Retrospektiven zur Verbesserung des Ablaufs (aus agilen Methoden übernommen).

Kanban und Scrum im Vergleich

Risiken, Stärken und Grenzen

Häufige Stolpersteine: Das Board wird zur bloßen Aufgabenliste ohne WIP-Limits; WIP-Limits werden bei Druck einfach erhöht; Karten bleiben lange liegen, weil niemand auf ihr Alter achtet; ohne feste Termine fehlen Reflexion und Verbesserung; große Karten verstopfen den Fluss.

Typische Gegenmaßnahmen: WIP-Limits ernst nehmen und Verstöße besprechen, das Alter laufender Karten täglich prüfen, regelmäßige Review- und Verbesserungstermine, Aufgaben in kleine, ähnlich große Karten schneiden.

Stärken: sehr leicht einzuführen, keine Umstellung bestehender Rollen nötig, hohe Transparenz, kurze Durchlaufzeiten, flexible Reaktion auf neue Aufgaben, gut messbar.

Grenzen: wenig Vorgaben für Produktentwicklung (kein Produktziel, keine Rollen), weniger Rhythmus für gemeinsame Planung und Reflexion, Gesamtumfang und Termine größerer Vorhaben nur über Flussdaten prognostizierbar.

Praxisbeispiele und Anwendungsfelder

Kanban eignet sich besonders für Support- und Service-Desk-Teams, Wartung und Betrieb, DevOps-Teams, Redaktionen, Personal- und Marketingabteilungen sowie für persönliche Aufgabenlisten (Personal Kanban). Beispiel: Das Redaktionsteam einer Schulwebsite führt alle Beiträge auf einem Board mit den Spalten „Idee – Schreiben – Korrektur – Freigabe – Online“ und begrenzt „Korrektur“ auf zwei Beiträge, weil nur zwei Lehrkräfte korrigieren; Termine wie der Elternsprechtag laufen über eine eigene Schwimmbahn mit fester Frist. Die Teamgröße ist flexibel, typisch sind Teams von zwei bis zehn Personen; viele Teams kombinieren Scrum mit einem Kanban-Board für das Sprint Backlog.

Leitfragen

1. Was sind Kanban-Board, WIP-Limit und Pull-Prinzip? Antwort

Das Board zeigt alle Aufgaben als Karten in Spalten für die Arbeitsschritte; das WIP-Limit begrenzt die Zahl der Karten je Spalte, damit erst fertiggestellt wird, bevor Neues beginnt; nach dem Pull-Prinzip zieht sich, wer frei ist, die nächste Karte, sofern das Limit der Zielspalte es zulässt, siehe Abschnitt „Grundprinzipien“.

2. Was passiert, wenn das WIP-Limit einer Spalte erreicht ist? Antwort

Es wird keine neue Karte in diese Spalte gezogen; stattdessen hilft das Team beim Engpass, bis dort wieder Platz ist. So wird der Stau sichtbar und abgebaut, statt weitere angefangene Arbeit anzuhäufen, siehe Abschnitt „Ablauf“.

3. Welche Flusskennzahlen nutzt Kanban, und wie hängen sie zusammen? Antwort

WIP, Durchsatz, Durchlaufzeit und Alter einer Karte. Nach Littles Gesetz ist die durchschnittliche Durchlaufzeit gleich durchschnittlichem WIP geteilt durch durchschnittlichen Durchsatz – weniger WIP verkürzt also die Durchlaufzeit, siehe Abschnitt „Planung und Kontrolle“.

4. Wie liest Du ein Cumulative Flow Diagram? Antwort

Es zeigt je Tag, wie viele Karten welche Spalte erreicht haben. Der senkrechte Abstand zwischen zwei Linien ist der WIP, der waagerechte Abstand die ungefähre Durchlaufzeit; ein breiter werdendes Band zeigt einen Stau, siehe Abschnitt „Planung und Kontrolle“.

5. Wie unterscheidet sich Kanban von Scrum? Antwort

Kanban kennt keine Sprints und keine festen Rollen, begrenzt Arbeit über WIP-Limits statt über den Sprintumfang, nimmt Änderungen jederzeit auf und misst den Fluss über Durchlaufzeit und Durchsatz; es eignet sich besonders für fortlaufende Arbeit mit unvorhersehbarem Eingang wie Support oder Wartung, siehe Abschnitt „Kanban und Scrum im Vergleich“.

6. Mit welchen Grundsätzen führt die Kanban-Methode Veränderungen ein? Antwort

Beginne mit dem, was Du jetzt tust; verfolge evolutionäre, gemeinsam vereinbarte Verbesserungen; fördere Führung auf allen Ebenen. Kanban ersetzt also keinen Ablauf, sondern macht ihn sichtbar und verbessert ihn schrittweise, siehe Abschnitt „Grundprinzipien“.

Links und weitere Informationen

• Vorgehensmodelle: klassisch und agil (Überblick und Vergleich)

• Scrum und DevOps

• Übungsaufgaben zu Vorgehensmodellen (u. a. ein Kanban-Board für den Support)

• als Nachschlagewerk: The Kanban Guide (Vacanti, Coleman u. a., Fassung Mai 2025)

• zum Weiterlesen: David J. Anderson: Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010

• historisch: Taiichi Ohno: Das Toyota-Produktionssystem (Originalausgabe 1978)

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Kanban: Arbeit sichtbar machen und begrenzen” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/kanban veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/vorgehensmodelle/vorgehensmodelle. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 30.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]