Kanban WIP Calculator

What it does

Calculate appropriate work-in-progress (WIP) limits for your Kanban board columns based on team size, average cycle time, and how focused you want the team to be on finishing-vs-starting. WIP limits are the number you cap each column at — no more than X tickets in “In Progress” at once. Without WIP limits, everyone starts everything and nothing gets finished. With them, the team is forced to swarm on completion before pulling new work.

The principle behind WIP limits is Little’s Law:

L = λW

Where L is the average number of items in the system (your WIP), λ is the arrival/throughput rate, and W is the average time an item spends in the system (cycle time). Solving for cycle time: W = L/λ. So if you have 20 things in progress and finish 4 per week, average cycle time is 5 weeks. Cut WIP to 8 and cycle time drops to 2 weeks (with the same throughput) — assuming you stop multitasking and focus.

The classic Kanban WIP formula: WIP per “In Progress” column = number of team members × focus factor (0.5-1.0). Focus factor of 1.0 = each person works on exactly one thing. 0.5 = each person can have up to 2 things in progress (rare in disciplined teams). For pair programming or swarm-style work, focus can drop to 0.25- 0.4 because multiple people work on each item. The tool asks for these inputs and returns suggested caps for each column.

How to use it

1. Enter team size — number of people who do the work, not stakeholders or PMs.
2. Set cycle time — average days from “Start work” to “Done”. If you don't have data, estimate; ideally measure for 4-8 weeks then refine.
3. Pick focus level: high (each person works on 1 thing), medium (each person can have 2), or low (lots of context-switching). High focus is what you should aim for; medium-low is what you usually have.
4. Read the suggested WIP limits for each column (To Do, In Progress, Review, Done).
5. Apply the limits to your Kanban tool (Jira, Trello, Linear, Notion). Track for 2-4 weeks; adjust based on actual flow.

When to use this tool

• Setting up a new Kanban board and need defensible starting WIP limits.
• Diagnosing a team that’s shipping slowly — too-high WIP is one of the most common causes.
• Convincing skeptical stakeholders that WIP limits matter — Little’s Law is empirical, not opinion.
• Planning a sprint capacity that respects realistic flow rates.

When not to use it

• Teams using pure Scrum (sprint-based) — Scrum has its own capacity-planning approach (story points, velocity) that doesn’t map cleanly to Kanban WIP.
• Highly creative or research work where outputs are deliberately unpredictable — WIP limits assume work flows; pure research doesn’t.
• Solo work — WIP limits are about coordinating multi-person flow.
• Teams that aren’t willing to enforce them — calculated limits are useless if everyone keeps pulling new work past the cap.

Common use cases

• Verifying a number or output before passing it on
• Quick calculation during a typical workday
• Pre-decision sanity-check on inputs and outputs
• Educational use — demonstrating the underlying concept