Written by the AgileFever editorial team. Facts checked on November 12, 2026 against the official pages of the organizations named in this post. AgileFever sells training for some of the topics covered here, and we say so wherever it applies. The two worked examples are made-up teams built to show the arithmetic. They are not client data or survey results.
Most guides to kanban WIP limits say to start low and adjust, without the arithmetic, so you finish reading with no number to type into your board. This post gives that number for two example teams, the three rules behind it, what to do when a column fills up, and a two-week tuning loop. If you do not have a board yet, start with our kanban board template.
What a WIP limit is and what the Kanban Guide says
A WIP limit is a cap on the number of work items that may be in progress at the same time, set per column, per person, per swimlane or for the whole board. When the cap is reached, nobody starts new work. They help finish what is already started.
The Kanban Guide from Kanban University (version 2025.5, updated May 1, 2025, checked November 12, 2026) defines WIP as the work items that sit between a started point and a finished point. It does not use the phrase “WIP limit” and gives no numbers. It requires the team to explicitly control the number of items in the workflow and to write down how it does that. The Guide says controlling WIP should produce a pull system, where new work starts only when there is capacity. It also defines the measures used later in this post: throughput is the number of items finished per unit of time, cycle time is the elapsed time from started to finished, and work item age is the elapsed time from started to today. Our post on Kanban principles vs practices shows where this control sits.
Why a lower WIP limit shortens cycle time
Little’s Law links three averages in a stable system: average cycle time equals average WIP divided by average throughput. If your team finishes 6 items a week on average and carries 24 items in progress, the average item takes 24 divided by 6, which is 4 weeks. Carry 12 items and finish the same 6 a week, and the average item takes 2 weeks.
Throughput held at 6 finished items a week. Cycle time in weeks equals WIP divided by 6.
Illustrative example. The numbers are an arithmetic demonstration, not data from a real team.
Two cautions. The law describes averages over a stable period, not any single card. And it assumes throughput stays the same when WIP changes. Once people or a bottleneck column run out of work, throughput falls and the gain disappears, so cut in steps and measure. Our post on kanban throughput covers how to count it.
Three ways to choose your first kanban WIP limits
No rule gives the right number for kanban WIP limits. Each gives a defensible starting point you then test against data.
| Rule | How to calculate it | Use it when | Weakness |
|---|---|---|---|
| 1. Team size | People working in a stage times 2 to 3 items, starting at the low end. Microsoft’s Azure Boards documentation (page dated March 24, 2026) gives this range and says to start low. | A new team with no history | Ignores how long work really takes. Three items each can already be too many. |
| 2. Observed average | Average number of started but unfinished items over 2 to 4 weeks, minus about 20%. The 20% is our suggestion. | A team that has worked for a month or more | Copies today’s habits, including bad ones. |
| 3. Flow-based | Throughput per week times target average cycle time in weeks. Then check work item age: items past your target while the column is full mean the limit is still too high. | A team with start and finish dates for 15 or more items | Needs dates. Average targets sit below the percentile you promise customers. |
For rule 3, pick the target from a service level expectation. If you promise that 85% of items finish within 10 working days, aim for an average of 8 working days, which is 1.6 weeks. The 85th percentile sits above the average, so this leaves room.
Worked example 1: a five-person development team
Illustrative example. Five people (three developers, one QA engineer, one tech lead) use a board with Ready, Build, Review, Test and Done. Over the last four weeks the team finished 7, 5, 6 and 6 items. A daily count of items started but not finished averaged 15.
| Step | Arithmetic | Result |
|---|---|---|
| Throughput | (7 + 5 + 6 + 6) / 4 weeks = 24 / 4 | 6 items a week |
| Current average cycle time | 15 items / 6 per week | 2.5 weeks, 12.5 working days |
| Rule 1, team size | 5 people x 2 to 3 items | 10 to 15 |
| Rule 2, observed average | 15 x 0.8 | 12 |
| Rule 3, flow-based | Target average 8 working days = 1.6 weeks; 6 x 1.6 = 9.6 | 10 |
| Chosen start | Rule 2, inside the rule 1 range | 12 in total |
Split the 12 across columns by who can do the work. Build gets 5: three developers with one item each, plus two items allowed for pairing. Review gets 4: the lead and two developers can review, plus one. Test gets 3: the QA engineer plus two items of slack. 5 + 4 + 3 = 12. Ready gets 6, one week of throughput, and is not counted in the 12 because nobody has started those items. At 6 finished a week, the expected average cycle time is 12 / 6 = 2.0 weeks, or 10 working days, down from 12.5.
After two weeks the team finished 6 and 7 items, so throughput is 13 / 2 = 6.5 a week. Build touched its limit on only 2 of 10 working days. Review sat at 4 on 7 of 10 days, and two items in Review were more than 5 days old. Review is the bottleneck, and Build feeds it faster than it drains. The change: Build goes from 5 to 4 and Review stays at 4. The total becomes 4 + 4 + 3 = 11, and the expected average cycle time is 11 / 6.5, about 1.7 weeks or 8.5 working days. The team did not raise the Review limit, because a larger queue there would only lengthen the wait.
Worked example 2: a four-person support team
Illustrative example. Four agents handle second-line cases that take days. The board has Triage, Investigating, Waiting on customer and Done. Over three weeks the team closed 12, 15 and 9 cases. A daily count of open cases averaged 20, because many sat waiting for customer replies. We count Waiting on customer as WIP, since the Guide counts anything between started and finished and the customer feels that wait.
| Step | Arithmetic | Result |
|---|---|---|
| Throughput | (12 + 15 + 9) / 3 weeks = 36 / 3 | 12 cases a week |
| Current average cycle time | 20 cases / 12 per week | 1.67 weeks, 8.3 working days |
| Rule 1, team size | 4 agents x 2 cases (Investigating only) | 8 |
| Rule 2, observed average | 20 x 0.8 | 16 for the whole board |
| Rule 3, flow-based | Target average 4 working days = 0.8 weeks; 12 x 0.8 = 9.6 | 10 |
| Chosen start | Rule 2 total, with rule 1 setting Investigating | 16 in total |
Set Triage at 2, Investigating at 8 (a per-agent limit of 2 each) and Waiting on customer at 6. 2 + 8 + 6 = 16, so the expected average cycle time is 16 / 12 = 1.33 weeks, or 6.7 working days. One swimlane is kept for urgent incidents. The team allows one open incident above the Investigating limit, so Investigating can reach 9 and no further.
Two weeks later the team closed 13 and 11 cases, which is 24 / 2 = 12 a week, unchanged. Waiting on customer was full on 8 of 10 days, and four cases had waited over 6 days without a reply. The change: Waiting on customer drops from 6 to 4, with a policy to nudge at day 3 and close at day 7. A full Waiting column now means chase before you pull. The total is 2 + 8 + 4 = 14, and the expected average cycle time is 14 / 12 = 1.17 weeks, about 5.8 working days. See Kanban for IT operations and support teams for more on this board.
Per-column, per-person and per-swimlane kanban WIP limits
Use the type that matches where work piles up. Most boards combine two kinds of kanban WIP limits.
| Type | How it works | Best for | Watch out for |
|---|---|---|---|
| Per column | Each workflow state has its own cap, as in both examples. | Making a bottleneck visible where it forms | Columns can look fine while the whole board is overloaded. Add a board-level total. |
| Per person | Each person may hold a set number of items, such as 2. | Support queues and teams where one person owns a case | Encourages solo work. Pair it with a swarming rule. |
| Per swimlane | Each lane (bugs, features, urgent) gets its own cap. | Mixed work types, and protecting capacity for urgent items | Many lanes dilute focus. Keep lanes to three or four. |
Our post on kanban board examples shows how software, marketing, HR and support boards set their kanban WIP limits differently.
What to do when a WIP limit is hit
A full column is information, not a failure. Write the response down as a policy.
- Swarm. Move to the oldest or most blocked item in the full column and help it finish.
- Pull right to left. Check the column nearest Done first, then work back. Pull from Ready only when the column you are filling is under its limit.
- Handle blocked items in place. Flag the card, name who can unblock it, and leave it in its column. It still counts as WIP. If it stays blocked for 2 working days, raise it at the next daily meeting.
- Allow one explicit exception. Many teams allow one urgent item over the limit. Write the rule on the board.
Microsoft’s documentation says exceeding a limit by one or two items is normal, and that exceeding it by three or more, consistently, calls for a review of the process or the limit.
Tune your kanban WIP limits after two weeks
Throughput for the last 14 days, average WIP, average cycle time, and the age of the oldest open item.
Count the days each column sat at its limit, and the days people had nothing to pull.
For each, ask what is blocking it. Compare ages with your service level expectation.
Write the change and the number you expect to move. Changing several at once hides the cause.
Put the date and the comparison number on the board.
Use this table to choose the change.
| Symptom | Likely cause | Change to try |
|---|---|---|
| A column sits at its limit most days and its oldest items keep aging | It is the bottleneck, or work arrives faster than it drains | Do not raise it. Swarm on its oldest item and lower the limit of the column that feeds it by 1. |
| A column rarely reaches its limit and the next column is starved | Limit too high, or the upstream supply is short | Check Ready first. If Ready holds cards, lower the limit by 1. |
| Open items pass your target age while limits are respected | Blocked work, or items too large | Apply the 2-day blocked rule. Split items to about 5 working days of work. |
| Throughput drops after a cut and people sit idle | The cut starved the bottleneck | Raise that column by 1 and compare after two weeks. |
| Cycle time did not change after a cut | Hidden work, expedites or blocked items missing from the count | Put all started work on the board and count blocked items. |
With only two weeks of data the numbers are rough. Wait for 15 to 20 finished items before you set a service level expectation. Our Kanban reports guide explains the charts that show these trends.
Spreadsheet formulas for your numbers
You need only start and finish dates for each item. The formulas below work in Excel and Google Sheets and reproduce the arithmetic for your own kanban WIP limits. The +1 counts the start day, so an item started and finished on the same day has a cycle time of 1.
Tab "Items" (one row per card) A: ID B: Started (date) C: Finished (date, blank while open) D2 (cycle time, days): =IF(C2="","",C2-B2+1) E2 (age, days): =IF(AND(B2<>"",C2=""),TODAY()-B2+1,"") Tab "Daily" (one row per working day, dates in column A) B2 (WIP at end of day): =COUNTIFS(Items!$B:$B,"<="&A2,Items!$C:$C,">"&A2)+COUNTIFS(Items!$B:$B,"<="&A2,Items!$C:$C,"") Tab "Summary" B1 Finished in last 28 days: =COUNTIFS(Items!$C:$C,">="&TODAY()-27,Items!$C:$C,"<="&TODAY()) B2 Throughput per week: =B1/4 B3 Average WIP, last 28 days: =AVERAGE(Daily!B2:B29) B4 Average cycle time, weeks: =B3/B2 B5 Average cycle time, work days: =B4*5 B6 First limit, observed average: =ROUND(B3*0.8,0) B7 Target average cycle time (weeks, your choice): 1.6 B8 First limit, flow rule: =ROUND(B2*B7,0) B9 85th percentile cycle time: =PERCENTILE(Items!D2:D500,0.85)
Prefer a ready-made tool? The AgileFever flow metrics tool is a free Kanban metrics tool. See also our free kanban board guide.
Mistakes that make kanban WIP limits fail
- Treating the limit as a target. A limit is a ceiling. Filling every column to its cap rebuilds the queues you removed.
- Ignoring blocked items. Moving a blocked card out of its column makes the board look healthy while work sits. Keep it in place and counted.
- Using one limit for everything. One number for the whole board hides the bottleneck. Bugs, features and urgent work also behave differently, so give them separate lanes.
- Cutting too far at once. Going from 15 to 5 starves people. Lower your kanban WIP limits about 20% at a time.
Where training fits
You can run everything above from this post. If you want to design the whole system, including WIP limits, pull policies and classes of service, in a Kanban University accredited course, AgileFever lists Kanban System Design (KSD). It teaches the Systems Thinking Approach to Introduce Kanban (STATIK). Read the product page for the current schedule, length and fee.
Questions people ask
What is a good WIP limit for a kanban board?
There is no universal number. A common start is 2 to 3 items per person in a stage, or about 20% below your observed average WIP. For a five-person team averaging 15 items in progress, that points to 10 to 12. Adjust after two weeks using age and throughput.
How do you set WIP limits in Kanban?
Count your throughput and average WIP, choose a starting limit by team size, observed average or the flow rule, and set it per column. Write what the team does when a column is full. Review after two weeks and change one limit by one.
What does the Kanban Guide say about WIP limits?
The Kanban Guide does not use the term or give numbers. It defines WIP as items between started and finished, and requires the team to explicitly control the number of items in the workflow. How, and how many, is the team’s decision.
What happens when a WIP limit is exceeded?
Stop pulling new work and swarm on the oldest or blocked item. Exceeding by one or two items occasionally is normal, but if it happens by three or more for days, review the limit and the process rather than ignoring it.
Should blocked items count toward the WIP limit?
Yes. A blocked item is started and not finished, so it is WIP. Leave it in its column, flagged with a reason and an owner. Removing it from the count lets the team start new work while the old item waits.
