Kanban Board Audit

One question decides most of this: are there WIP limits, and do they ever stop anyone? Without that, you have visibility and none of the flow benefit.

Team / board: _______________ Date: _______ Audited by: _______________

1. Does the board show the real workflow?#

• [ ] Columns match how work actually moves, not an idealised process
• [ ] Waiting states are columns — waiting for review, for test environment, for another team, for a decision
• [ ] Steps outside the team's control are shown, even though the team cannot fix them
• [ ] A blocked item is visibly blocked, with the reason and who is chasing

🔴 Delay lives in the queues, not in the work. A board that omits the waiting states measures the small part of the process you control and leaves everyone puzzled about the lead time.

Columns currently on the board: _______________ Waiting states NOT shown: _______________

2. WIP limits — the mechanism#

• [ ] A limit exists per column (or across the board)
• [ ] Limits are visible on the board
• [ ] The limit is reached regularly — if never, it is doing nothing
• [ ] When it is reached, people help finish rather than starting something new
• [ ] Limits were adjusted based on evidence, not set once and forgotten

If "times exceeded" is high, the limit is decorative. A limit that is routinely broken is a suggestion, and the board has quietly become a push system with nicer columns.

3. Explicit policies#

• [ ] "Ready" is defined — what must be true before an item can be pulled
• [ ] "Done" is defined per column
• [ ] Prioritisation rule written down
• [ ] Expedite policy written down: what qualifies, how many at once, what it displaces
• [ ] Policies are visible, not folklore

Unwritten policies get applied inconsistently and argued about weekly.

4. Expedites#

• [ ] Expedite lane exists and is limited (usually to one)
• [ ] Used rarely — count last month: ____
• [ ] Each expedite has a recorded justification

If more than a small fraction of work is expedited, priority is being set by whoever asks loudest, and the ordinary queue has stopped moving.

5. Is the board true?#

• [ ] Every item in progress has actually been worked on this week
• [ ] Nothing has sat in one column for more than ____ days without a flag
• [ ] Work being done is on the board — no invisible side work
• [ ] Items are updated as they move, not in a weekly tidy-up

Oldest item in progress: ____ days. What is stopping it? _______________

Those two questions do most of the work in a weekly review.

6. Metrics#

• [ ] Cycle time measured (start of work → done)
• [ ] Lead time measured (request → delivered) — usually much longer than the team expects
• [ ] Throughput tracked (items per week)
• [ ] Forecasts use the distribution of past cycle times, not an average
• [ ] Metrics describe the system, never individuals

Flow efficiency is frequently under 20% on first measurement. That is uncomfortable and useful: it says the problem is queues, not effort.

Forecast as "85% of items finish within ___ days" rather than "average ___ days" — the average hides the tail that causes every escalation.

7. Improvement#

• [ ] Someone looks at where work accumulates, regularly
• [ ] A constraint has been fixed in the last quarter — which: ____________
• [ ] The team has a scheduled improvement conversation (kanban does not mandate one; teams without one usually stop improving)

Verdict#

"No" to the first two means this is a to-do list on a wall. That still has some value, and it is not kanban — and the flow improvement everyone is expecting will not arrive.

Back to Kanban