Wann verwende ich Kanban?
- Stephan Bellmann
- 20. Jan.
- 4 Min. Lesezeit
Kanban im Projektmanagement: Entscheidungsparameter, Einsatzbereiche und praktische Anwendungsbeispiele
Inhalt
Einordnung
Kanban ist im Projektmanagement besonders dann sinnvoll, wenn die Realität nicht aus sauber planbaren Arbeitspaketen besteht, sondern aus dynamischen Anforderungen, ständigem Nachschub und vielen parallelen Themen. Der Kern von Kanban ist dabei nicht „mehr Planung“, sondern eine bessere Steuerung des Arbeitsflusses durch Transparenz, Fokus und kontinuierliche Verbesserung.
📝Artikel: Was ist Kanban?
Scrum nutzt du, wenn du in einem komplexen Umfeld regelmäßig planbare Produkt-Inkremente in festen Iterationen (Sprints) liefern willst und dafür klare Rollen, Events und ein Sprint-Commitment brauchst.
🎤 Interview: "Scrum oder Kanban - Studienanalyse und Praxiseinordnung mit Felix Huschka" - Felix Huschka
Wann nutze ich Kanban im Projektmanagement?
Kontinuierlicher Arbeitsfluss statt Sprintarbeit
Kanban eignet sich vor allem dann, wenn ein kontinuierlicher Arbeitsfluss im Vordergrund steht. Typisch ist das bei Aufgaben, die laufend entstehen und nicht sinnvoll in feste Iterationen oder Sprintziele "gepresst" werden können. Kanban setzt hier auf das Pull-Prinzip: Neue Arbeit wird erst dann begonnen, wenn Kapazität frei ist – statt immer mehr Aufgaben „hineinzuschieben“. Dadurch entsteht ein stabiler Flow und weniger Chaos.
Häufig wechselnde Prioritäten
Auch bei häufig wechselnden Prioritäten ist Kanban besonders geeignet, weil es nicht auf ein festes Sprint-Commitment angewiesen ist. Stattdessen wird die Reihenfolge der Aufgaben über ein priorisiertes Board laufend angepasst. Unterstützt wird das durch klare Policies, also einfache Regeln wie „Expedite hat Vorrang“ oder „Blocked Items werden zuerst gelöst“.
Hohe Varianz in Umfang und Dauer der Aufgaben
Ein weiterer wichtiger Parameter ist die hohe Varianz in Umfang und Dauer von Aufgaben. Wenn manche Dinge in einer Stunde erledigt sind und andere mehrere Tage brauchen, wird Sprintplanung oft ungenau oder künstlich. Kanban funktioniert hier gut, weil der Fokus nicht auf gleich großen Arbeitspaketen liegt, sondern auf einem fließenden System, das über Durchsatz und Durchlaufzeit (Lead Time / Cycle Time) gesteuert wird.
Viele parallele Themen / Multitasking / Überlast
Kanban ist außerdem sehr hilfreich, wenn ein Team unter zu vielen parallelen Themen, Multitasking oder Überlast leidet. Hier sind WIP-Limits (Work in Progress) eine zentrale Praktik: Das Team begrenzt bewusst, wie viele Aufgaben gleichzeitig in Bearbeitung sein dürfen. Dadurch wird „Stop starting – start finishing“ praktisch umgesetzt und die Wahrscheinlichkeit steigt, dass Arbeit wirklich abgeschlossen wird.
Viele Abhängigkeiten, Übergaben oder Wartezeiten
Bei vielen Abhängigkeiten, Übergaben oder Wartezeiten spielt Kanban ebenfalls seine Stärke aus. Übergänge zwischen Rollen (z. B. Umsetzung → Review → Test → Freigabe) werden als Workflow sichtbar gemacht. Blocker lassen sich gezielt markieren und priorisieren, sodass Engpässe nicht versteckt bleiben, sondern aktiv gelöst werden. So wird das System Schritt für Schritt robuster.
Fokus auf Durchlaufzeit und Lieferfähigkeit
Wenn das Ziel vor allem bessere Lieferfähigkeit und kürzere Durchlaufzeiten ist, passt Kanban besonders gut. Statt auf „Planerfüllung“ zu optimieren, wird die Arbeitsfähigkeit über Flow-Praktiken gesteuert und über Kennzahlen wie Cycle Time oder Aging Work Items greifbar gemacht. Das macht Lieferperformance realistisch messbar – und kontinuierlich verbesserbar.
Geteilte Kapazität im Team (Linie + Projekt + Betrieb)
Kanban eignet sich auch sehr gut, wenn Teammitglieder geteilte Kapazitäten haben, also parallel Linie, Betrieb und Projekt bedienen. In solchen Settings sind feste Sprintzusagen oft schwierig. Kanban erlaubt eine realistischere Steuerung über Pull und WIP, weil es sich stärker an tatsächlicher Kapazität orientiert als an Wunschplanung.
Agile Erfahrung / Selbstorganisation als Voraussetzung
Wichtig ist dabei: Es ist von Vorteil, wenn das Team bereits agile Erfahrung und Selbstorganisation mitbringt. Im Gegensatz zu Scrum gibt es bei Kanban nur wenig feste Strukturen und keine verpflichtenden Rollen oder Events. Das ist flexibel und leichtgewichtig, verlangt aber ein gewisses Reifelevel, damit Kanban nicht nur als „Ticketboard“ genutzt wird, sondern wirklich als Steuerungssystem funktioniert.
🎤 Interview: "Kanban ist mehr als ein Board" - Robin Gamperl
Beispiele aus der Praxis (3 typische Kanban-Anwendungen)
Beispiel 1: IT-Support / Service Desk (Incidents & Requests)
Kontext:
Ein internes IT-Team bekommt täglich neue Themen rein:
Passwort zurücksetzen
VPN geht nicht
Laptop defekt / neues Gerät einrichten
Softwarezugänge / Berechtigungen
kleinere Störungen (Incident) und Nutzeranfragen (Request)
Warum Kanban hier passt
Die Arbeit kommt kontinuierlich rein, ist oft dringend, und Prioritäten ändern sich schnell. Mit Kanban kann das Team über Pull steuern: Es wird erst neue Arbeit gestartet, wenn Kapazität vorhanden ist.
Typisches Board (Beispiel):
Intake / Eingang
Triage (Priorisierung)
In Progress
Waiting / Blocked (z. B. wartet auf User/Hardware)
Done
Typische Kanban-Praktiken:
WIP-Limit z. B. „max. 3 Tickets gleichzeitig in Progress“
Klassen von Service: „Expedite“ (kritisch), „Standard“, „Fixed Date“ (z. B. Rollout-Termin)
Fokus auf Cycle Time: „Wie schnell lösen wir ein Ticket wirklich?“
Ergebnis: weniger Chaos, weniger paralleles Anfangen, schnelleres Abarbeiten und bessere Planbarkeit im Alltag.
Beispiel 2 (neu): Marketing-/Content-Team (Kampagnen, Posts, Assets)
Kontext:
Ein Marketing- oder Kommunikations-Team arbeitet kontinuierlich an:
LinkedIn-Posts / Artikel / Newsletter
Website-Updates / Landingpages
Kampagnenmaterial (Grafiken, Videos, Copy)
Event-Kommunikation
interne Abstimmungen mit Sales, Brand, Legal
Warum Kanban hier passt:
Die Arbeit läuft kontinuierlich, Prioritäten ändern sich oft („das muss noch diese Woche raus“), und es gibt viele Warte- und Freigabeschleifen (z. B. Feedback von Stakeholdern, Brand-Freigabe, Rechtsprüfung). Kanban ist hier ideal, weil es den Workflow sichtbar macht, Engpässe offenlegt und über WIP-Limits verhindert, dass zu viel parallel „halb fertig“ liegen bleibt.
Typisches Board (Beispiel):
Ideen / Backlog
In Erstellung
Review / Feedback
Freigabe (Brand/Legal)
Geplant / Scheduled
Veröffentlicht / Done
Typische Kanban-Praktiken:
WIP-Limits z. B. „max. 2 Inhalte gleichzeitig in Erstellung“→ erhöht Fokus und sorgt für fertiggestellte Outputs statt Dauer-Offenposten
Explizite Policies: z. B. „Keine Freigabe ohne finalen Text + Visual + Zielgruppe“
Blocked/Waiting sichtbar machen (z. B. wartet auf Fachinput)
Messen über Cycle Time: „Wie lange braucht ein Post von Idee bis Veröffentlichung?“
Ergebnis: Weniger Verzögerungen durch Feedbackschleifen, bessere Planbarkeit, höhere Output-Qualität und deutlich mehr Transparenz für alle Beteiligten.
Kommentare