A Practical Guide to Setting Work in Progress Limits in Kanban

Work in progress, or WIP, is the unfinished work currently moving through a team’s system. In Kanban, limiting that work is a way to protect flow, expose bottlenecks and help people finish valuable tasks before starting new ones. A WIP limit is not simply a number written above a column. It is a management decision about capacity, priorities and the behaviour a team wants its workflow to encourage.

This guide explains how to set useful limits, test them in daily work and adjust them without turning Kanban into a rigid rulebook. The approach fits software teams, engineering groups, manufacturing support, research projects and office-based operations. It also reflects the kind of digital visual planning and lean process research presented through the Project Visit overview, where visibility is treated as a foundation for better collaboration.

Start With The Work System

A WIP limit applies to a defined part of a workflow, so the first task is to make that workflow visible. A basic board might contain options such as Ready, Analysis, Development, Review, Testing and Done. The names matter less than the agreement behind them. Everyone should understand when an item enters a column, what activity takes place there and what evidence is required before it moves on.

Avoid setting limits against vague categories such as “the whole project” unless the team has no more useful boundary. A limit for the entire board can hide the real constraint. If six items are active but five are waiting for testing, the development column may appear healthy while testing is overloaded. Limits work best when they reveal where queues form.

The unit of work also needs attention. A card could represent a customer request, a software change, a machine modification, a research experiment or a document needing approval. When cards vary greatly in size, a limit of five does not mean five equal amounts of effort. Splitting oversized items, identifying blocked work and separating urgent classes can make the numbers more meaningful.

For an Australian organisation, the system may include people spread between Melbourne, Brisbane and Perth, suppliers operating in different time zones or field crews who are away from the office. A digital board must show ownership and status clearly enough that a quick “no worries, I’ll pick that up” is still recorded as a real commitment rather than an invisible side task.

Measure Before Choosing Numbers

Teams often begin with a number that feels comfortable: three items per person, five cards in development or one task for every specialist. These figures can be useful starting points, but they are hypotheses rather than facts. Before choosing a limit, observe how work currently behaves. Track how many items are active, how long they remain active and where they wait.

The most useful measures are usually straightforward:

• WIP: the number of active items at a given time.
• Cycle time: the elapsed time from starting work to finishing it.
• Throughput: the number of items completed in a selected period.
• Age: how long each unfinished item has already been active.
• Blocked time: time spent waiting for information, approval, access or another team.

A team does not need a sophisticated enterprise system to collect these measures. A physical board, spreadsheet or lightweight visual management tool may be enough for an initial trial. The important point is to distinguish active work from work that is merely visible. An item awaiting a vendor response is still part of WIP if the team remains responsible for finishing it.

Little’s Law provides a useful relationship between these measures: average WIP is approximately equal to throughput multiplied by average cycle time. It is not a calculator for setting a perfect limit, especially when demand is unstable, but it clarifies the trade-off. If throughput stays constant, carrying more unfinished work generally increases the time each item spends in the system.

Set An Initial Limit That Encourages Finishing

A practical starting limit is often slightly below the team’s current average WIP in a constrained activity. If a review column usually contains eight items, trying a limit of six may expose the queue without stopping work immediately. If the team is new to visual management, a smaller limit can create a useful finishing habit, provided people have a clear response when the limit is reached.

Capacity is affected by more than headcount. A team of six may have only one person qualified to approve safety documentation, two people who can test a particular integration and a part-time subject-matter expert shared across several projects. The limit should reflect these constraints. Counting people alone can encourage overloading the specialist who is actually controlling the flow.

A good initial limit should answer three practical questions. What behaviour should change? Which queue is most damaging? What will the team do when the limit is full? If the answer to the last question is “start another item anyway”, the team has not yet agreed on the purpose of the limit. The expected response may be swarming, helping with testing, clarifying requirements or escalating a dependency.

Urgent work requires explicit treatment. A “fast lane” with unlimited entry quickly defeats the system, particularly in service environments where every request is described as urgent. Set a small emergency capacity, such as one item, and define who can use it. In an Australian utilities, construction or healthcare context, safety and regulatory work may need priority, but routine management preference should not be allowed to borrow the same exemption.

Make Limits Visible And Usable

A WIP limit should be visible where decisions are made. On a physical board, write the number above the column and make blocked items easy to recognise without creating a forest of stickers. On a digital board, display the count, capacity and ageing items together. A limit that exists only in a policy document will not influence daily behaviour.

The number should be paired with a working agreement. When a column is full, the default action is to stop pulling new work into it. Team members then look for ways to move existing work forward. They might pair on a difficult task, review someone else’s output, resolve a dependency or improve a test environment. This changes the question from “What can I start?” to “What is preventing completion?”

The board should also show exceptions honestly. If an item is blocked by a customer decision in Sydney, a supplier in regional New South Wales or an approval from a global office, mark that state and record the next expected event. Hiding blocked work to keep the columns under their limits creates attractive but inaccurate reporting.

Useful signals for daily management include:

• A column at or above its limit for several consecutive days.
• One item becoming much older than the team’s normal cycle time.
• Regular movement of cards backwards between columns.
• A growing queue before a specialist, approval step or test environment.
• Frequent bypassing of the limit through informal side work.

Practical review prompts for the weekly replenishment or flow meeting include:

• Which limit caused the team to stop starting and help finish?
• Which limit was too high to expose a meaningful constraint?
• Which items were counted as active even though they were waiting?
• Did an urgent class protect a genuine need or become a convenience?
• What single change would improve flow before the next review?

Treat The Limit As A Testable Hypothesis

A WIP limit is best treated as a small operational experiment. Select a limit, state the expected effect and observe the result for a defined period. Two weeks may be enough for a stable support team; a hardware or research workflow may need several weeks because its work cycles are longer. Avoid changing the number every day in response to a single unusual event.

Look for evidence across several dimensions. Has average cycle time fallen? Are fewer items ageing dangerously? Is throughput stable or improving? Are people collaborating across roles rather than waiting for one specialist? Has the queue moved somewhere else? A reduction in one column is not automatically a success if it creates a larger queue downstream.

Teams can also compare scenarios. If a development limit of four leads to an empty test column, the development constraint may be too tight, or testing may need earlier preparation. If a limit of eight keeps developers busy but causes cycle time to double, the extra activity is probably creating delay rather than capacity. The goal is a smoother system, not maximum occupancy at every stage.

Research, industry collaboration and prototype tools can help organisations explore these questions without assuming that one board design suits every setting. Teams interested in related visual planning work can review project contact details when looking for a suitable research or industry connection. The value lies in testing the relationship between visibility, decisions and flow in the actual work environment.

Adapt Limits To People And Demand

Limits should evolve when the system changes. A new product release, seasonal demand, staff rotation, regulatory requirement or supplier disruption can alter the effective capacity of a workflow. In Australia, summer shutdowns, public holidays, mining or construction cycles and long-distance logistics may create patterns that are invisible in a short measurement window. Record these conditions rather than treating every variation as team performance.

Do not respond to every delay by increasing a limit. If work is waiting for a decision, extra items usually increase confusion. If a specialist is overloaded, adding more cards creates a larger queue. First identify whether the constraint is capacity, quality, unclear input, dependency management or prioritisation. The remedy may be cross-training, better entry criteria, smaller work items or a change in approval policy.

A limit can also be different for different classes of work. Standard work may have a normal capacity, while fixed-date work has a controlled allowance. The distinction should be visible on the board and reviewed regularly. If an emergency class consumes the majority of capacity, the organisation has a demand or service-design problem, not a reason to keep expanding the exception.

The language used by the team matters. A limit is not a punishment for being busy, and reaching it is not a failure. It is information about the current system. In a workplace where people say “she’ll be right” to move past an uncomfortable queue, the board should make the cost of that optimism visible. A short, factual conversation about ageing work is more useful than blame.

Build A Sustainable Flow Habit

The strongest WIP limits are supported by regular replenishment and delivery decisions. Replenishment selects the next work only when capacity is available. Delivery removes finished items promptly instead of leaving them in a completed column that still looks active. Review and retrospective conversations then examine whether the system is helping the organisation meet its service promises.

Keep the number of limits manageable. A team does not need a separate rule for every colour, role and exception. Start with the narrowest point where waiting is visible, then add detail only when it improves a decision. Too much configuration can make the board technically precise but practically ignored.

Leaders have a particular responsibility. If managers continually inject new work, ask for private status updates or reward multitasking, the team receives a message that limits are optional. Leaders should use the board to negotiate priorities, remove obstacles and protect finishing work. They should also accept that an honest full column may be healthier than a falsely busy team.

Visual planning is ultimately a way to improve conversations about work. A board cannot resolve a poor product decision, an underfunded test environment or an impossible deadline by itself. It can show where those problems appear and create a shared basis for action. For teams exploring wider approaches to visible work and movement through systems, practical movement research offers a related perspective on how activity and coordination can be understood in context.

Begin with one workflow, count the current items and choose a trial limit for its clearest bottleneck; write the number and the review date on the board today.