WIP-Limits: So legen Sie sie in Kanban fest (mit Beispielen)

Work-in-Progress-Limits (WIP-Limits) gehören zu den schnellsten Wegen, um zu verbessern, wie zügig Arbeit durch ein Team fließt. Setzen Sie eine Zahl über jede Spalte Ihres Kanban-Boards, und die Regel ist einfach: Niemand beginnt neue Arbeit, wenn die Spalte bereits ihr Limit erreicht hat.

Key Facts

• Teams, die WIP-Limits konsequent durchsetzen, berichten laut einer Praktiker-Umfrage der Kanban University (2023) von doppelt so schnellen Durchlaufzeiten wie Teams ohne Limits.
• Kontextwechsel kosten Arbeitskräfte im Schnitt 23 Minuten, um sich nach einer Unterbrechung wieder vollständig zu fokussieren, was sich verstärkt, wenn mehrere Aufgaben gleichzeitig laufen (University of California, Irvine, 2023).
• Das durchschnittliche Software-Team arbeitet pro Person an 3 bis 5 aktiven Aufgaben gleichzeitig, doch der höchste Durchsatz wird typischerweise mit 1 bis 2 Aufgaben pro Person erreicht (State of Agile Report, 17. Ausgabe, 2024).

Was sind WIP-Limits?

WIP-Limits (Work-in-Progress-Limits) sind explizite Obergrenzen dafür, wie viele Elemente zu einem gegebenen Zeitpunkt in einer bestimmten Phase eines Workflows existieren dürfen. In einem Kanban-System steht jede Board-Spalte für eine Phase, und das WIP-Limit steht als Zahl über dieser Spalte. Erreicht eine Spalte ihr Limit, zieht niemand neue Arbeit hinein, bis etwas vorrückt.

Das Konzept stammt direkt aus der Lean-Fertigung, wo Toyota ein System namens "Kanban-Karten" nutzte, um den Produktionsfluss in der Fabrikhalle zu steuern. Die Idee war, dass Überproduktion Verschwendung ist, und dasselbe Prinzip gilt für Wissensarbeit: Je mehr Dinge Sie beginnen, ohne sie abzuschließen, desto langsamer wird alles.

WIP-Limits sagen Ihnen nicht, woran Sie als Nächstes arbeiten sollen. Sie sagen Ihnen, wann Sie aufhören sollten, neue Dinge zu beginnen, und anfangen sollten, bestehende abzuschließen.

Warum Work in Progress begrenzen?

Die Begründung für WIP-Limits beruht auf einer Formel namens Little's Law, die besagt:

Durchlaufzeit = WIP / Durchsatz

Einfach ausgedrückt: Hat Ihr Team 20 Elemente in Arbeit und schließt 5 pro Woche ab, beträgt die durchschnittliche Durchlaufzeit 4 Wochen. Reduzieren Sie WIP auf 10 Elemente, sinkt die Durchlaufzeit auf 2 Wochen, ohne dass das Team härter arbeitet.

Die Rechnung klingt fast zu sauber, aber der zugrunde liegende Mechanismus ist real. Das passiert ohne Limits:

Kontextwechsel zerstört Fokus. Jedes Mal, wenn jemand eine neue Aufgabe aufnimmt, bevor eine alte abgeschlossen ist, zahlt diese Person mentale Wechselkosten. Diese Kosten sind nicht trivial. Forschung der UC Irvine beziffert ihn auf über 20 Minuten verlorenen Fokus pro Unterbrechung. Multiplizieren Sie das mit 3-5 gleichzeitigen Aufgaben pro Person, und Sie haben still und leise den Großteil eines Arbeitstags allein für Übergangsaufwand verbraucht.

Lange Warteschlangen verstecken Probleme. Wenn sich Arbeit in einer Spalte staut, wird sie unsichtbar. Niemand bemerkt, dass eine Review-Aufgabe seit drei Tagen unangetastet liegt, weil das Board so überfüllt ist, dass die Verzögerung nicht auffällt. WIP-Limits legen diese Engpässe sofort offen. Erreicht die Spalte "In Review" ihre Obergrenze, muss das Team darüber sprechen, warum Elemente nicht vorankommen.

Flow-Kennzahlen spiegeln das direkt wider. Nutzen Sie ein Cumulative-Flow-Diagramm, sind breite Bänder in den mittleren Phasen ein visuelles Zeichen für hohen WIP. Schmale, parallele Bänder bedeuten, dass WIP unter Kontrolle ist und Arbeit fließt. Auch die Velocity in Agile verbessert sich meist, sobald WIP-Limits stabilisieren, wie viel sich das Team pro Zyklus vornimmt.

So legen Sie WIP-Limits fest

Es gibt keine universelle Formel, die für jedes Team funktioniert. Aber diese Schritte geben Ihnen einen Ausgangspunkt, den Sie im Laufe der Zeit anpassen können.

Schritt 1: Die Kapazität Ihres Teams zählen

Beginnen Sie mit der Anzahl der Personen, die in jeder Phase arbeiten. Eine Entwicklungsspalte mit 4 Entwicklern kann mehr gleichzeitige Elemente bewältigen als eine Review-Spalte, die von 1 oder 2 Personen betreut wird.

Eine gängige Faustregel: 2 Elemente pro Person pro Spalte. Eine Entwicklungsspalte mit 4 Personen startet also mit einem WIP-Limit von 8.

Schritt 2: Ihren aktuellen tatsächlichen WIP betrachten

Bevor Sie Limits festlegen, zählen Sie, wie viele Elemente heute tatsächlich in jeder Spalte liegen. Das ist Ihre Baseline. Hat die Spalte "In Progress" für ein 3-köpfiges Team bereits 14 Elemente, haben Sie ein klares Bild davon, warum Arbeit so lange braucht.

Schritt 3: Limits leicht unter Ihrem aktuellen Durchschnitt festlegen

Liegt Ihr durchschnittlicher WIP pro Spalte bei 10, starten Sie Ihr Limit bei 7 oder 8, nicht bei 3. Ein zu enges Limit verursacht mehr Störungen, als es löst, besonders am Anfang. Das Team soll die Einschränkung spüren und reagieren, nicht gelähmt sein.

Schritt 4: Das Limit als Gesprächsanstoß durchsetzen, nicht als harte Blockade

Erreicht eine Spalte ihr Limit, besteht die Aufgabe des Teams darin, sich auf die blockierte Arbeit zu konzentrieren und sie zu klären, bevor etwas Neues hereingezogen wird. Hier ändern WIP-Limits das Teamverhalten. "Können wir helfen, dieses Element durch die Review zu bringen?" wird zur täglichen Gewohnheit statt zu einer Nachbetrachtung.

Schritt 5: Alle zwei Wochen überprüfen und anpassen

Schauen Sie nach zwei Sprints oder zwei Wochen auf Ihr Burndown-Chart und Ihre Durchlaufzeit-Daten. Fließen Elemente schneller, verschärfen Sie die Limits. Fühlt sich das Team dauerhaft blockiert, lockern Sie sie eine Stufe. WIP-Limits sind ein Regler, keine in Stein gemeißelte Regel.

WIP-Limits nach Board-Spalte

Hier eine Referenztabelle für ein typisches Software-Team mit einem vierspaltigen Kanban-Board. Das sind Ausgangspunkte, keine Vorschriften.

Für ein Team von 4 Entwicklern ist eine sinnvolle Startkonfiguration: To Do (unbegrenzt), In Progress (6), In Review (3), Done (unbegrenzt). Das verhindert, dass die Entwicklungsspalte zum Engpass wird, und hält die Review schlank.

Nutzt Ihr Team Scrum mit zweiwöchigen Sprints, können Sie WIP-Limits auf dieselbe Weise auf das Sprint-Board anwenden. Die Logik ist identisch, auch wenn die Einordnung anders ist. Die Unterscheidung Scrum vs. Kanban ändert nichts an der zugrunde liegenden Mathematik von Little's Law.

Häufige Fehler beim Festlegen von WIP-Limits

Limits setzen und ignorieren. Ein WIP-Limit, um das herum Teams navigieren, existiert nicht wirklich. Wenn das Team die Obergrenze regelmäßig mit "Ausnahmen" umgeht, wird das Limit nicht durchgesetzt. Bauen Sie erst die Gewohnheit auf, bevor Sie den Prozess aufbauen.

Eine einzige Zahl auf jede Spalte anwenden. Eine Review-Spalte mit 2 Reviewern und eine Entwicklungsspalte mit 5 Entwicklern haben einen völlig unterschiedlichen Durchsatz. Eine Größe passt hier für niemanden.

Das Limit zu schnell zu niedrig ansetzen. Fallen Sie über Nacht von 15 Elementen pro Spalte auf 3, erzeugen Sie Panik und Widerstand. Schrittweise Verschärfung gibt dem Team Zeit, Workflows anzupassen und die Probleme sichtbar zu machen, die hoher WIP verdeckt hat.

Blockaden vergessen. WIP-Limits zählen auch blockierte Elemente. Sind 3 Ihrer 6 "In Progress"-Aufgaben durch externe Abhängigkeiten blockiert, haben Sie nur 3 Plätze echter Kapazität. Blockaden separat zu verfolgen, hält das Bild akkurat.

Nicht für Story Points anpassen. Manche Teams legen Limits nach Elementanzahl fest, andere nach Story Points. Variieren Ihre Aufgaben stark in der Größe (eine 1-Punkte-Aufgabe neben einem 13-Punkte-Epic), zählen Sie nach Punkten, um ein ehrlicheres Bild der Auslastung zu erhalten.

Vorteile von WIP-Limits

Wenn Teams ihre Limits tatsächlich durchsetzen, passieren durchgängig ein paar Dinge:

Arbeit wird schneller abgeschlossen. Die Durchlaufzeit sinkt, weil Elemente nicht wartend liegen bleiben. Kann das Team nur 5 Dinge gleichzeitig bearbeiten, bekommt jedes dieser 5 Elemente tägliche Aufmerksamkeit.

Engpässe werden sofort sichtbar. Eine Spalte, die immer an ihrem Limit liegt, sagt Ihnen etwas. Das Team kann sie nicht ignorieren, weil sie alles andere blockiert.

Teamgespräche verbessern sich. WIP-Limits schaffen natürliche Momente, um zu fragen "warum steckt das fest?", statt Verzögerungen unsichtbar werden zu lassen. Daily Standups konzentrieren sich stärker auf dieselbe Frage: Was blockiert den Fortschritt gerade jetzt?

Planung wird ehrlicher. Sieht das Team eine volle Spalte, hört es auf, sich zu neuer Arbeit zu verpflichten, die es nicht bewältigen kann. Überplanung sinkt, und die Prognosegenauigkeit verbessert sich. Das hängt direkt damit zusammen, wie sich Velocity in Agile stabilisiert, sobald WIP unter Kontrolle ist.

Stress sinkt. Paradoxerweise ist es weniger stressig, zu hören "Sie können nur an 5 Dingen arbeiten" als "Werden Sie mit allen 15 fertig". Menschen wissen, worauf sie sich konzentrieren sollen.

---

WIP-Limits sind eine kleine Änderung mit überproportionaler Wirkung auf den Team-Flow. Sobald Sie zum ersten Mal einen Engpass sichtbar werden sehen, weil eine Spalte ihre Obergrenze erreicht hat, "klickt" der Mechanismus. Von da an geht es nur noch darum, die Zahlen feinzujustieren. Verfolgen Sie Ihre Durchlaufzeiten mit einem Cumulative-Flow-Diagramm und beobachten Sie, was mit den Bändern passiert, wenn WIP sinkt.