Too much work in progress is easy to defend and hard to survive. Every item has a reason. A customer is waiting. A leader asked. A defect appeared. A developer had spare time. Soon the board looks busy, but finished work slows down. People are working, yet the system is not delivering.

This diagnostic is useful for people considering Kanban System Design training or Kanban Management Professional certification. It gives you a way to inspect flow before adding more process.

The flow diagnostic

Question	What it reveals	First response
Where does work wait longest?	The real constraint, not the loudest complaint.	Mark queue states separately from active work.
How many items are started but not finished?	WIP pressure.	Set a visible WIP limit and respect it for two weeks.
Who can pull new work?	Policy clarity.	Write the pull policy where the team can see it.
Which item gets interrupted most?	Priority churn.	Name the source of interruption.
What percentage of work is unplanned?	Demand volatility.	Track planned and unplanned work separately.
Which work type has no service expectation?	Predictability gap.	Define basic service expectations by work type.

Visual boards are not enough

Many teams say they use Kanban because they have columns. A board is only the start. The real power comes from explicit policies, WIP limits, service thinking, flow metrics, and regular improvement. Without those, the board becomes a prettier task list.

A team should be able to answer simple questions. When can work enter this column? Who can pull it? What does done mean here? What happens when the WIP limit is reached? If the answers differ by person, the system is running on habit, not policy.

The hidden queue problem

The biggest queue is often not shown. Work waits in email, stakeholder approval, testing environment, design review, architecture decision, or product clarification. If the board shows only active development, the team cannot see the real system.

Map the waiting states. Do not worry if the board becomes less flattering. Visibility is the point. You cannot improve a queue that stays hidden.

Metrics that help without creating fear

Start with three measures: work in progress, cycle time, and blocked time. Do not use them to punish individuals. Use them to understand the system. If cycle time is rising, ask where work waits. If blocked time is high, ask who can remove the constraint. If WIP is high, stop starting and start finishing.

For a deeper metric discussion, read Kanban metrics that help teams finish more work. For formal learning, KSD helps design the system and KMP helps manage improvement over time.

A two-week experiment

• Separate waiting states from active work.
• Set one WIP limit where overload is most visible.
• Track blocked items daily.
• Stop pulling new work when the limit is reached.
• Review what finished, not only what moved.
• Change one policy based on evidence.

How Scrum teams can use this

Kanban is not only for teams without Scrum. Scrum teams can use Kanban thinking to improve flow inside the sprint. If work always piles up before testing, make that queue visible. If stories carry over because too many are started, use WIP limits. If refinement creates vague items, create a clear pull policy for ready work.

Closing view

Too much WIP is not a personal discipline problem. It is a system design problem. Kanban helps teams see the system, limit overload, and improve delivery without pretending that busyness equals progress.

A workshop to reveal hidden WIP

Ask each person to write down every item they are currently thinking about, not only items on the board. Include review requests, waiting approvals, support tickets, half-started analysis, follow-ups, and work sitting in email. Then compare the list with the visible board. The difference is hidden WIP.

This exercise is uncomfortable because it shows how much work the system has already accepted. Do not use it to blame people. Use it to redesign policies. If work enters through email, create an intake policy. If urgent work interrupts everything, define what urgent means. If review queues are invisible, add them to the board.

The best first change is usually small. Limit one overloaded column. Make one waiting state visible. Track one blocked reason. When teams see finished work improve, they become more willing to discuss deeper changes. Flow improvement grows from evidence, not speeches.

How to use this guide at work

Share this guide with one small group first. Do not send it to the whole organisation and hope people change. Pick the people closest to the problem: a Product Owner and Scrum Master, a project manager and delivery lead, an RTE and Business Owner, or a manager and team representative. Read the checklist together and mark what is already true, what is partly true, and what is missing.

The value comes from the discussion, not from agreeing with every line. If someone disagrees, ask for an example from current work. If the example is strong, adjust the checklist for your context. If the example is only an opinion, keep the discussion grounded in what the team can observe. This keeps the guide from becoming another theoretical article saved in a browser tab.

End with one decision. It might be a course choice, a policy change, a meeting redesign, a backlog cleanup, a readiness review, or a safer AI rule. Write the owner and review date. A guide becomes useful only when it changes one working habit.