WIP Limit Kanban Throughput
Calculate WIP limits, kanban throughput, and flow efficiency for your team. Optimize agile workflows and identify bottlenecks with this free kanban tool.
Formula
Cycle Time = WIP / Throughput
Little's Law states that the average time an item spends in a system (Cycle Time) is equal to the number of items in the system (WIP) divided by the average completion rate (Throughput). To speed up delivery, you must lower WIP.
Worked Examples
Example 1: Dev Team
Problem:WIP Limit 5 items. Throughput 2 items/day.
Solution:Cycle Time = 5 / 2 = 2.5 Days.
Result:2.5 Days Avg Cycle Time
Frequently Asked Questions
What is Little's Law?
A theorem from queuing theory: Avg number of items in a system (L) = Avg arrival rate (λ) × Avg time in system (W). In Kanban: WIP = Throughput × Cycle Time.
Why limit WIP?
Limiting WIP reduces context switching, exposes bottlenecks (queues), and improves Cycle Time. It forces the team to swarm on blocked items rather than starting new ones.
What is a good WIP limit?
A common heuristic is 1.5 × Number of Team Members. Or, start with current WIP and reduce by 20% until it hurts. Lower is usually better until flow starves.
What is Flow Efficiency?
Active Work Time / Total Cycle Time. If a task takes 10 days but you only worked on it for 1 day (8 hours), efficiency is 10%. World class is >40%.
How does WIP affect quality?
Lower WIP improves quality because feedback loops are faster. If you find a bug 2 hours after coding it, it's cheap to fix. If you find it 2 weeks later, it's expensive.
What is 'Slack' in Kanban?
Idle time. In Kanban, having people idle is okay if the *work* is flowing. Maximizing 'Resource Utilization' (100% busy people) guarantees 100% traffic jams.
Difference between Kanban and Scrum?
Scrum limits WIP via timeboxes (Sprints). Kanban limits WIP via explicit column limits. Scrum resets every 2 weeks; Kanban is continuous.
How to handle Blockers?
Blockers count towards the WIP limit. This forces the team to resolve the blocker before pulling new work. If you ignore blockers, WIP explodes.
What is Cumulative Flow Diagram (CFD)?
A chart showing the count of items in each state over time. Widening bands indicate growing WIP (bottlenecks). Parallel bands indicate stable flow.
Can I use Kanban for personal tasks?
Yes! 'Personal Kanban' (To Do, Doing, Done) with a WIP limit of 2-3 in 'Doing' prevents overwhelm.
Background & Theory
The WIP Limit Calculator demonstrates Little's Law: Cycle Time = WIP / Throughput.
Concept Overview
- WIP (Work In Progress): The number of items started but not finished.
- Throughput: Items finished per time unit (Velocity).
- Cycle Time: How long an item takes from Start to Finish.
- Little's Law: To reduce Cycle Time (deliver faster), you must either increase Throughput (work harder) or reduce WIP (do less at once). Reducing WIP is free; working harder is not.
Key Variables & Intuition
- Flow Efficiency: The ratio of "Touch Time" (Coding) to "Queue Time" (Waiting for Review). Most process efficiency is <15%.
- Context Switching: Every active task adds cognitive load (20% penalty per extra task). High WIP destroys IQ.
Assumptions
- The system is stable (Average arrival rate = Average departure rate).
- Units of work are roughly comparable in size (or average out).
Limitations & Edge Cases
- Blockers: High WIP is often a symptom of blockers. Reducing WIP exposes these blockers painfully (which is good).
- Starvation: If WIP is too low, people sit idle. The goal is to balance Flow vs Utilization.
- Classes of Service: "Expedite" lanes break standard Little's Law assumptions by jumping the queue.
Practical Tips
- Start with what you do: Visualize the current mess before adding limits.
- Limit column, not person: "Max 3 items in Testing," not "Max 3 items per Tester." This forces collaboration.
- Stop Starting, Start Finishing: The mantra of Kanban.
Common Mistakes
- Setting WIP limits but ignoring them when "urgent" work comes in.
- Measuring "Lead Time" (Customer Request -> Done) and calling it "Cycle Time" (Start -> Done). Be consistent.
- Focusing on "Resource Utilization" (keeping people busy) instead of "Flow Efficiency" (keeping work moving).
History
Kanban (Japanese for "Signboard") originated on the floor of Toyota factories in the 1940s, evolving into the dominant agile software methodology.
Origins & Why It Emerged
Taiichi Ohno developed Kanban to implement "Just-in-Time" (JIT) manufacturing. Supermarkets were the inspiration: shelves were only restocked when customers bought product. This "Pull System" replaced the "Push System" (building inventory regardless of demand), drastically reducing waste.
How It Evolved in Practice
In 2004, David J. Anderson applied Kanban to software development at Microsoft. He introduced the core practices: Visualize Work, Limit WIP (Work in Progress), and Manage Flow. It solved the problem of "Scrum" sprints feeling artificial for maintenance/support teams who needed continuous flow.
Modern Usage Today
Kanban is ubiquitous in DevOps, Support, and Manufacturing. Tools like Trello, Jira, and Asana visualize the board. "Personal Kanban" helps individuals manage life. The metric "Flow Efficiency" is now a key KPI for elite engineering teams (DORA metrics).
Common Misconceptions
- "Kanban means no deadlines": No, it means probabilistic forecasting based on Cycle Time.
- "It's just a board": The board is a visualization. The System requires WIP limits. Without limits, it's just a to-do list.
- "WIP Limit = Laziness": Limiting WIP increases throughput by reducing context switching. This is counter-intuitive but mathematically proven (Little's Law).