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.
- 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
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
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
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.
- Definieren Sie Release-Meilensteine auf der Gantt-Timeline.
- Filtern Sie Board-Spalten nach Meilenstein oder Tag für Release-Readiness-Reviews.
- 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
QA-Testläufe in die Delivery integrieren
Testpläne und Runs gehören neben Features und Bugs — nicht in eine abgekoppelte Tabelle.
Read articleProjekt-Reporting-Software: Throughput, Auslastung und gespeicherte Ansichten
Hören Sie auf, Jira-CSVs für Steering-Meetings zu exportieren. Gespeicherte Report-Templates aggregieren Tasks, Bugs und Testergebnisse aus demselben Graphen wie Ihr Board.
Read articleSales-Pipeline-Software: gewichtete Prognose und Deal-Boards in einem Workspace
Hören Sie auf, Tabellen mit dem CRM abzugleichen. Verfolgen Sie Deals auf einem Kanban-Board, berechnen Sie die gewichtete Prognose aus der Stage-Wahrscheinlichkeit und wandeln Sie Gewinne in Angebote um — neben Delivery und Support.
Read article

