A WIP limit is the maximum number of items a board column (or the whole system) may have in progress at the same time. When the column is full, the team stops starting and helps finish. Limiting work in progress cuts context switching, exposes bottlenecks and, by Little's Law, shortens cycle time without asking anyone to work faster.
How to use
- Enter how many people pull work on the board and the average throughput per week.
- List the in-progress columns, in board order, with the current items and the current limit (if any).
- If you know it, enter how many people work in each column: the suggested limit becomes more precise.
- Read the columns over the limit, the likely bottleneck and the estimated cycle time before and after.
- Apply one limit at a time, watch the board for two weeks and adjust.
What each field asks for
| Field | What to enter |
|---|---|
| People on the team | Those who pull work on the board. Basis for the suggested total limit. |
| Throughput (items per week) | Average items delivered per week over recent weeks. |
| Column | E.g. Development |
| Items now | Including blocked ones. |
| Current limit | Blank if there is none. |
| People | Optional. |
Example
A team of 6 people delivers 5 items a week and has 23 items in progress, 3.8 per person. Analysis (4 against a limit of 3) and Development (9 against 6) are over the limit, and Code review, with no limit and no dedicated people, holds 5 items: it is the likely bottleneck. By Little's Law, cycle time today is 4.6 weeks (about 32 days). Keeping to its own limits, it would fall to 3.8 weeks; with the suggested limits (2, 4, 1, 2 and 1, 10 items in total), to 2 weeks.
When to use
- When setting up the team's first board and needing a starting point for the limits.
- When cycle time keeps growing for no obvious reason and many items are started at once.
- To show leadership, with numbers, the effect of starting less and finishing more.
- In the regular board review, to check whether the limits still make sense.
Frequently asked questions
How do I set the WIP limit for a column?
A common starting point is the number of people working in the column plus one, to absorb blockers. It is not a rule: the right limit emerges from watching the board for a few weeks and adjusting one step at a time.
What should the total board limit be?
A convention used as a starting point is around 1.5 items per team member. Above 2 items per person, context switching usually lengthens cycle time noticeably.
How does the simulator find the bottleneck?
It points to the column with the highest load relative to its limit (yours or, without one, the suggested one). It is a signal: confirm it by looking at where items wait longest and whether the column before it sits idle waiting for space.
How is cycle time estimated?
With Little's Law: average cycle time is work in progress divided by throughput. The simulator caps each column at its limit and keeps current throughput, which is a conservative assumption.
Do waiting columns count?
Yes. Queues such as "waiting for review" or "ready for testing" are work already started and count towards WIP. Only the entry (to do) and exit (delivered) columns are left out.
What should we do when a column hits its limit?
Stop pulling new items into it and help finish what is already there: review, test, unblock. Raising the limit to fit more work hides the bottleneck instead of solving it.