WIP limit
A WIP limit is a cap on how many work items may be in a given stage of a kanban board at once, so that the team finishes what is started before pulling new work in. It is a policy the team sets and enforces on itself: when a column is full, the next item waits, and whoever would have pulled it helps clear the column instead.
The longer version
The limit is written on the column header and applies to the count of cards in that column, sometimes to the whole board. When a developer finishes a feature and the QA column is at its limit, the feature cannot move; the developer either helps test what is already there, or fixes what QA has found, or waits. That discomfort is the mechanism. The limit makes the bottleneck visible on the board rather than in a manager's sense of it, and it forces the conversation about why QA is the bottleneck instead of quietly stacking work on it. Limits are set by the team, tried, and adjusted.
A WIP limit is confused with a WIP column and with a sprint commitment. A column named WIP, or In Progress, is a stage on the board and says where a ticket is; a WIP limit is a number attached to a stage and says how many may be there. A board can have the column with no limit, which is where most teams start, and the limit is what turns a board from a status display into a flow control. A sprint commitment caps how much work is started per iteration; a WIP limit caps how much is in flight at any moment, regardless of iteration, and the two coexist.
A limit set too high never bites, so nothing waits and nothing changes. A parallel column circumvents one that does bite: Blocked, Waiting for review, Almost done, each an unlimited holding pen that keeps the limited column technically honest. They also fail on tickets that are unequal, when one card is an afternoon and the next is a month, and a count-based limit treats them alike. The response is smaller tickets rather than a bigger limit. A limit is working when it is hit sometimes and the team can say what it did about it.
Common questions
What is a WIP limit in kanban?
A maximum number of cards allowed in one column of the board at the same time, written on the column header and enforced by the team. When the column is full, nobody pulls new work into it; they finish or help finish what is there. The limit exposes where work piles up and converts that pile into a conversation rather than a queue.
How do you set a WIP limit?
Start from what is in the column today and set the limit slightly below it, so it bites within the first week. Roughly the number of people who can work that stage, or a little more, is the usual starting point for a column. Then watch: a limit never reached is too high, and a limit reached daily with no change in behaviour is being routed around. Adjust in the retrospective, not mid-week.
What happens when a WIP limit is reached?
The next item waits in the column before it, and the person who would have pulled it works on clearing the full column instead: pairing on a review, testing a ticket, fixing what QA found, or unblocking a stuck card. The point is to swarm the bottleneck. Teams that respond by raising the limit, or by adding a holding column, have removed the mechanism and kept the ceremony.
What is the difference between a WIP limit and a sprint commitment?
A sprint commitment caps how much work the team starts in one iteration, and it is set once at planning. A WIP limit caps how many items may be in one stage at any moment, regardless of the iteration, and it is enforced continuously. A team can honour its sprint commitment and still have every story in progress and none finished, which is the situation a WIP limit exists to prevent. The two are used together.
Who enforces a WIP limit?
The team, on itself. The limit is a policy the people working the board agreed to, and enforcement is the moment a developer sees a full column and helps clear it instead of pulling a new card. A manager can ask why a limit was breached and cannot make it work by policing it, because the point is the conversation the team has at the bottleneck. A board tool can flag a full column; none can hold the conversation.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.