What needs to be finished first
The workflow is understood, with main stages and handoffs known, so Kanban columns map to real stages.
The team accepts a shared visible board as the single source of truth for work in flight.
What needs to be ready before start
Physical board or digital tool (Jira, Linear, Trello, Azure Boards); card schema with title, owner, class of service, and due date; WIP limit signage per column; cumulative flow diagram (CFD) for reporting.
One service delivery manager or team lead as flow owner; all team members as card movers; optional flow manager for multi-team setups; stakeholders with read access.
Backlog with pending items; definition of ready and definition of done per column; current per-person load; known external dependencies; SLA or delivery goals.
Setup 2-4 h, then continuous operation with daily stand-up (15 min) and weekly replenishment (45 min)
Align columns to real work stages (for example backlog, ready, in progress, in review, done). Set conservative WIP limits per column (persons in column minus 1). Define done criteria per column in writing. Define class of service (Standard, Expedite, Fixed Date, Intangible).
The one question this method answers
How does work flow through the stages, where does it queue up, and which policy keeps WIP limits intact?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Visualize | 2-4 h setup | Capture all active items as cards and place them in the matching column. Assign owner per card. Mark class of service. Make the board visible to everyone. | If 30 cards are marked in progress while the team has 5 people, overload is the primary issue, not process design. |
2Phase 2: Set WIP limits | 1 h | Set a hard limit per column. Rule of thumb: people in the column minus 1, or 1.5 per person when pair work is common. Limit must be visible on board. | When the team treats limits as recommendations, there is no true limit. Before adopting, commit explicitly: when exceeded, stop-the-line. |
3Phase 3: Policies and pull | 30 min | Anchor pull rule: no one pushes, everyone pulls. Run daily stand-up at the board, read from right to left. Mark blockers with red cards. Define escalation path clearly. | If a manager pushes work to the board without capacity, WIP limits have no effect. Managers should introduce work at replenishment, not directly in doing. |
4Phase 4: Measure and visualize | ongoing | Track CFD and lead time per card. Use lead time histogram as forecast basis. Hold monthly flow review with bottleneck analysis. | Lead time without distribution hides variation. Report median and 85th percentile. If lead time varies strongly, class of service is unclear or items are inconsistent in size. |
5Phase 5: Continuous improvement | 45 min per month | Flow review: identify where waiting builds, where WIP limits are broken, and which class of service is overloaded. Define one to two improvement actions per review. | Kanban is not set-and-forget. Without review, the board becomes a tracker, not a control instrument. Keep changes to at most two per review or causal links weaken. |
What comes out at the end
Living Kanban board with columns, WIP limits, classes, cards, and policies, plus CFD, lead-time histogram, and monthly review notes with improvements and outcomes.
Where possible, version board configuration as code (Jira configuration export). Monthly snapshot of CFD and lead-time histogram in Confluence or wiki. Document all changes to columns or WIP limits with date and rationale.
Compact working template for Kanban with context, input, output artifacts, and next step.
What is this method used for?
Which question should be answered at the end?
Which data, observations, or materials are available?
Owner, date, success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Columns and limits
Classes of service
Current state
Flow metrics (rolling 4 weeks)
Top bottleneck: In Review (reviewer capacity). Measure from KW 19: Pair review slot Tue/Thu 14:00-15:30, owner @ben. Success signal: 85th percentile lead time below 14 days within 6 weeks.
Recognize symptoms and steer against them
Columns are generic To Do/Doing/Done and do not map real stages; cards stay stuck in Doing.
Align columns to real work flow, with at least ready, in progress, in review, verify. Define entry and exit criteria per column.
Limit of 3 is regularly exceeded by 5 or 6 without consequence.
Introduce stop-the-line: when exceeded, no new work starts. Complete existing work first. WIP discipline becomes real when limits are treated as agreements.
A manager or PM pushes cards into Doing without capacity.
Define replenishment meeting as the only path to ready. Doing must be pull-only. Under pressure, use class of service Expedite with explicit rules rather than informal escalation.
Several people assume someone else is working on an item, and cards stall.
Pull rule: whoever pulls is owner. Require owner avatar on every card. If no one pulls, keep card in ready, not assign by default.
All cards look the same, and expedite tickets crowd out standard work without rules.
Define four classes with slots and rules. Expedite should have one slot and not stall the whole flow; fixed date requires date field on each card.
Diagram exists but nobody reviews it, and bottlenecks remain invisible.
Run monthly flow review as recurring meeting. CFD and lead-time histogram must be required slides. Attack one bottleneck per review.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.