What's the relationship between Cycle Time, WIP, and Throughput?

What's really being asked

This question isn't a vocabulary quiz. It tests your understanding of system dynamics and flow. The interviewer wants to see if you can apply a fundamental principle of queueing theory (Little's Law) to software development. They are evaluating your ability to reason about process improvements and predict their second-order effects. It separates candidates who just know buzzwords from those who understand the underlying mechanics of team productivity.

The full answer

A strong answer has three parts. First, clearly define the terms: Work in Progress (WIP) is the number of tasks actively being worked on; Throughput is the rate at which tasks are completed (e.g., 3 tasks per week); and Cycle Time is the average time it takes to complete one task from start to finish. Second, state the relationship, known as Little's Law: Average Cycle Time = Average WIP / Average Throughput. Third, explain the effect of lowering WIP limits. Lowering WIP directly reduces the number of concurrent tasks. This forces the team to finish existing work before starting new work, which reduces context switching and exposes bottlenecks. The primary, predictable effect is a reduction in Cycle Time. Throughput might temporarily dip as the system adjusts but should stabilize or even improve in the long run as the team becomes more efficient.

The mistakes people make

A major red flag is confusing the terms, especially Cycle Time (time from 'start work' to 'done') with Lead Time (time from 'request' to 'done'). Another common mistake is making overly simplistic predictions. Stating that "lowering WIP increases throughput" is a wrong answer. While it can be a long-term outcome of improved flow, it's not the direct, guaranteed result. The direct result is shorter cycle times. A weak answer just states the formula without explaining the 'why'—the reduction in context switching and the focus on finishing.

What usually comes next

Be prepared for "How would you introduce WIP limits to a team that doesn't have them?" or "What if you lower WIP limits and throughput collapses? What would you investigate?" Another common follow-up is "When might you want to increase WIP limits?" (e.g., to absorb a temporary spike in capacity or to deliberately expose a downstream bottleneck).

A concrete example

Imagine a team has an average WIP of 10 stories and their throughput is 2 stories per week. Little's Law predicts their average cycle time is 10 / 2 = 5 weeks per story. The team decides to lower their WIP limit to 5. Initially, they can't start new work, so they swarm on the 5 oldest items. They finish them faster. Now, with a WIP of 5 and a stable throughput of 2 stories/week, the new predicted cycle time is 5 / 2 = 2.5 weeks. The team delivers value twice as fast, even though their overall output rate hasn't changed.