What is a WIP limit in kanban?

A WIP limit is the most work items allowed in a column, for a person, or on the whole board at once. When the limit is reached, the team finishes or unblocks existing work before starting anything new.

How do I set my first WIP limit?

A common starting point is one item in progress per person doing the work, plus a small limit on any review or testing column. Treat it as a starting point, not a rule, and adjust it at a regular review based on what got stuck.

Does the Kanban Guide require WIP limits?

The 2025 Kanban Guide requires teams to explicitly control the number of work items between started and finished, and to define how. A number on each column is the common way, but a written rule such as one item per person also counts.

Can I set a WIP limit on fenbs?

Not as a setting. fenbs has four fixed lanes and no limit per lane. Teams keep a limit by agreement, write it in the board’s AI context so assistants read it too, and check it with the count shown beside the In Progress lane.

WIP Limits in Kanban: How to Set Them

A WIP limit caps how many items may be in progress at once, so a team finishes work before it starts more. What the Kanban Guide actually asks for, a first limit for teams of three, six and ten, and what to do when a column is full.

28 September 20267 min read

A kanban board with WIP limits caps how many items may sit in a column, or on the whole board, at the same time. When a column reaches its limit, nobody pulls anything new into it; they help finish what is already there. To set a first limit, count the people who actually do the work, set the In Progress limit at that number, and adjust it every couple of weeks by looking at what got stuck. The number matters less than the habit: a limit only works if the team treats a full column as a signal to finish, not as a suggestion.

This piece is about setting and keeping the limit. For the board itself, see what is a kanban board. For measuring whether the limit is helping, see cycle time vs lead time.

What the Kanban Guide actually asks for

The 2025 edition of the Kanban Guide (opens in a new tab) by John Coleman and Daniel Vacanti does not use the phrase “WIP limit” as a rule. It says Kanban system members “must explicitly control the number of work items in a workflow from started to finished”, and that the control can be shown on the board however the team sees fit. WIP itself is defined plainly: the number of work items started but not finished. The guide also asks that any accepted exceptions to the control are written down as part of the team’s definition of workflow.

The 2025 edition deliberately made this looser than before: its own list of changes says it is less explicit about how WIP is controlled. So a number over a column is one way to comply, and a written rule such as “one card in progress per person” is another. What the guide does not allow is no control at all.

Other sources are more concrete about the mechanics. Kanban University’s guide (opens in a new tab) says a WIP limit can be set per work state, per person, per lane, per type of work or for the whole system, and is usually drawn as a number above the column.

The Agile Alliance’s glossary entry for the kanban board (opens in a new tab) gives the classic example: if a testing column has a limit of two, the team may not start testing a third story while two are already being tested.

Why a limit helps

Every item in progress is a promise that has not been kept yet. With too many open, each one moves slowly, context switching eats the day, and the board shows plenty of activity and very little finished. A limit forces the question “what would it take to finish something?” before “what shall I start?”. The GOV.UK Service Manual’s introduction to agile methods (opens in a new tab) lists controlling the amount of work you are doing as one of the things Kanban helps a team to do, alongside finding bottlenecks and predicting output from actual delivery.

Rules of thumb for a first limit

None of these comes from a guide. They are common practice, and they are starting points to be adjusted, not answers:

Start at one item in progress per person doing the work. It is easy to explain and easy to check.
If people often wait on each other, such as for a review, allow one extra for the whole team, not one extra each.
Limit the columns where work waits, such as review or testing, as well as the ones where it is done. A queue with no limit is where finished work goes to age.
Pick a number slightly lower than feels comfortable. A limit that never bites teaches nothing.
Change it only at a regular review, never in the middle of a busy week to make room for one more card.

Examples for teams of three, six and ten

The same thinking scales, but the shape changes as a team grows. These assume a board with a queue of ready work, a column for doing, and a column for review before done.

A team of three

In Progress: 3. Review: 2. With three people, most blockages are one person waiting for another to look at their work, so the review limit matters as much as the doing limit. When Review is full, whoever is free reviews before pulling anything new.

A team of six

In Progress: 5. Review: 3. One fewer than the headcount nudges people to pair on the hardest item rather than each carrying their own. If two specialists never overlap, such as design and back end, some teams set a small limit per type of work instead, so one kind cannot crowd out the other.

A team of ten

In Progress: 7 to 8. Review: 4. At this size a single board limit hides who is overloaded, so many teams add a per-person rule of no more than two items each, or split into two boards with their own limits. An urgent item that must jump the queue gets one agreed slot of its own, written down in advance, rather than breaking the limit whenever someone shouts. Kanban swimlanes covers expedite lanes and when they hide work.

When a column is full: stop starting, start finishing

The limit earns its keep on the day it is reached. The instinct is to raise it or to start something “small” on the side. Instead, work right to left across the board:

Can anything waiting for review or testing be checked now? Reviewing someone else’s work is the fastest way to free a slot.
Is anything in progress blocked? Spend the time unblocking it: chase the answer, make the decision, fix the environment.
Can you join someone on the oldest item in progress? Two people finishing one thing beats two things half done.
Is anything in progress no longer worth doing? Stop it deliberately and move it back, with a note saying why.
Only when none of those apply is it worth asking whether the limit is too low, and that question belongs at the next review, not this afternoon.

An idle hour when the board is full is not waste. It is the signal the limit exists to send: the constraint is somewhere else, and that is where help is needed.

Signs the limit is wrong

Too high: the limit is never reached, items sit in progress for weeks, and the stand-up is a list of things “still going”.
Too low: people are regularly idle with nothing to help with, and the queue in front of the doing column grows every week.
Ignored: cards are left in To Do while people work on them “unofficially”. That is the worst case, because the board has stopped telling the truth.

The measure to watch is how long items take from start to finish and how old the items in progress are. If the limit comes down and those fall, it is working. Cycle time vs lead time shows how to work them out.

Hard limits and soft limits

Some tools block a card from entering a full column; many only warn. GitHub’s documentation for the board layout in GitHub Projects (opens in a new tab) says a column limit highlights the count when it is exceeded but does not stop anyone, or any automation, from adding cards. That is not a flaw. A limit is a team agreement first; the tool only makes it visible. A team that ignores a warning will find a way round a block too.

WIP when AI agents are on the board

An AI agent does not feel overloaded, so it will pull card after card until something stops it. That makes a per-worker limit, usually one item per agent session, more important than a column limit. Kanban for AI agents covers how lanes and limits change when agents do some of the work, and a kanban board for Claude Code shows a limit of one in practice.

Keeping a WIP limit on fenbs

fenbs has no WIP limit setting. A board has four fixed lanes, To Do, Next Up, In Progress and Completed, and nothing stops a fifth card entering In Progress. So on fenbs a limit is a team agreement, and the board helps you keep it rather than enforcing it:

Count it. Each lane shows the number of tasks in it beside its name, and the Insights panel above the board has an In Progress tile. If the agreed limit is four and the lane says six, that is the conversation for today.
Write it down where everyone reads it. Put the limit in the board’s AI context as a How we work note, so every connected AI assistant reads it on arrival alongside the people who agreed it.
Check who pulled what. The History records every move with who made it, so you can see which person or AI assistant moved each task into In Progress, and the task’s own page lists its activity.
Keep Next Up short. Next Up is the queue people pull from; if it is always full, there is no pressure to finish before starting.

A WIP rule as an AI context note

How we work: work in progress
- In Progress holds at most 4 tasks across the whole team.
- At most 1 per AI assistant session.
- If the lane is full: review, unblock or help finish. Do not start.
- One exception: a P1 bug may go in over the limit. Say so in a comment.

The four lanes and why they are fixed: what is a lane. Other boards and the one rule each needs: kanban board examples. Where limits fit alongside sprints: what is Scrumban.