Blog

Kanban-Boards für agile Teams: ein praktischer Leitfaden

So strukturieren Sie Spalten, WIP-Limits und Übergaben, damit Ihr Board echte Delivery abbildet — nicht nur Ticket-Verschieben.

Updated 2026-07-2210 min read
  • Kanban
  • Agile
  • Boards

Warum Kanban für Delivery-Teams weiterhin überzeugt

Scrum-Zeremonien geben Rhythmus, doch die meisten Produkt- und Engineering-Teams arbeiten im Continuous Flow. Kanban macht unsichtbare Arbeit sichtbar: Code-Review-Warteschlangen, QA-Engpässe, Staging-Deployments und Kunden-Eskalationen erscheinen als Spalten — nicht versteckt in Statusfeldern.

  • Pull-basierter Flow reduziert Context Switching gegenüber push-lastigen Sprint-Plänen.
  • WIP-Limits machen Engpässe sichtbar, bevor Deadlines verrutschen.
  • Dieselben Karten speisen Listenansichten, Gantt-Zeitpläne und gespeicherte Reports — ohne Doppelpflege.

Bilden Sie zuerst Ihren realen Workflow ab

Beginnen Sie damit, wie Arbeit heute wirklich fließt. Sprechen Sie mit Entwicklern, QA und Support. Zeichnen Sie den Weg von der Idee bis zur Production — inklusive Review, Test, Deploy und Kundenverifizierung.

  1. 1

    Listen Sie Ihre Zustände auf

    Schreiben Sie jede Übergabe auf: Backlog, In Progress, In Review, QA, Staging, Done. Vermeiden Sie generische Labels wie „In Progress“, wenn sie mehrere Schritte verbergen.

  2. 2

    Spalten zusammenführen oder aufteilen

    Wenn QA und Staging eine Spalte teilen, aber unterschiedliche Owner haben, trennen Sie sie. Wenn zwei Spalten nie Karten halten, führen Sie sie zusammen, um Rauschen zu reduzieren.

  3. 3

    Mit den Projekteinstellungen abstimmen

    Konfigurieren Sie in Projectman Workflow-Spalten pro Projekt, damit Board, Liste und Reports dieselben Status verwenden.

WIP-Limits setzen, die Teams auch einhalten

Work-in-Progress-Limits sind Vereinbarungen, keine Strafen. Sie erzwingen Gespräche: „Warum ist Review blockiert?“ statt still weitere gestartete Tasks hinzuzufügen.

  • Setzen Sie Limits pro Spalte anhand der Teamgröße (z. B. Review-WIP = Anzahl der Reviewer).
  • Verfolgen Sie in Reports die Cycle Time von „In Progress“ bis „Done“, um Limit-Änderungen zu validieren.

Boards mit Gantt und Reports verbinden

Boards zeigen heute; Gantt zeigt den Horizont; Reports zeigen Trends. In Projectman teilen sie einen gemeinsamen Work-Item-Graphen. Wenn Leadership nach Throughput oder überfälliger QA fragt, antworten Sie aus gespeicherten Report-Templates — nicht mit manuellen Exports.

  1. Definieren Sie Release-Meilensteine auf der Gantt-Timeline.
  2. Filtern Sie Board-Spalten nach Meilenstein oder Tag für Release-Readiness-Reviews.
  3. Planen Sie einen wöchentlichen gespeicherten Report (Issues nach Status, Assignee, Alter) für das Steering.

Häufige Fehler, die Sie vermeiden sollten

  • Ein Template-Board kopieren, ohne es an Ihre Deployment-Pipeline anzupassen.
  • Das Board nur für Tasks nutzen, während Bugs und Features woanders leben.
  • Retro-Daten ignorieren — wenn Spalten nie ändern, ist das Board Dekoration.

Continue reading