Software teams often measure velocity or story points, but delivery speed is really a flow problem: how long does an item take from start to finish, how many are in progress at once, and where does it wait? Flow metrics answer those questions from data the team already has.
This guide covers cycle time, lead time, throughput, and WIP, explains Little's Law, shows how to forecast with percentiles instead of estimates, and works through a team's 20 completed items, including what a WIP limit would do.
Before You Start
Why Flow Metrics Matter
Work Waits More Than It Is Worked
Most of an item's elapsed time is spent waiting in queues, for review, for a build, for someone else. Flow metrics make that visible.
Too Much in Progress Slows Everything
Every extra item in flight adds waiting and context switching. Limiting work in progress usually speeds delivery.
Forecasts Beat Estimates
Cycle time distributions from your own history give a more honest forecast than point estimates for individual items.
Bottlenecks Show Up
Where work piles up between stages is where the system is constrained.
The Core Measures
| Measure | Definition | Use |
|---|---|---|
| Cycle time | Time from when work starts on an item to when it is done | Predict delivery, find delays. |
| Lead time | Time from request to delivery, including waiting before work starts | The customer's view of speed. |
| Throughput | Number of items completed per unit of time | Capacity and forecasting. |
| Work in progress (WIP) | Number of items started but not finished | Control queues and delay. |
| Age of work in progress | How long each open item has been in progress | Spot stuck items early. |
Little's Law
For a stable system, average WIP = throughput × average cycle time. Rearranged, average cycle time = average WIP / throughput. If throughput stays the same, cutting WIP cuts cycle time in proportion. See the Little's Law entry and, in service settings, the backlog example.
Worked Example: One Team's Cycle Times
A team completed 20 work items over 20 working days. Their cycle times, in working days, sorted, were: 2, 3, 3, 4, 4, 5, 5, 5, 6, 6, 7, 7, 8, 9, 10, 12, 14, 18, 23, 30. The numbers are illustrative.
| Measure | Value |
|---|---|
| Items completed | 20 in 20 working days = throughput of 1 item per day |
| Mean cycle time | 181 / 20 = 9.05 days |
| Median cycle time | (6 + 7) / 2 = 6.5 days |
| 85th percentile | 14 days: 85% of items finished within 14 days |
| 95th percentile | 23 days |
| Average WIP implied by Little's Law | 1 item per day × 9.05 days ≈ 9 items |
Forecasting. The team tells stakeholders that a new item will usually be done within 14 days, with an 85% likelihood, rather than promising six or seven days. That statement comes from history, not from an estimate of each item.
WIP limit. The team averages about 9 items in progress. If they cap WIP at 6 and throughput stays at 1 item a day, Little's Law predicts an average cycle time of about 6 days, a one-third reduction. The assumption matters: throughput may fall if the limit starves a stage, so the team tries the limit for a few weeks and watches throughput, cycle time, and the age of items in progress. Look at the tail too: the three items that took 18, 23, and 30 days are where investigation pays off, since they are blocked, not just slow.
Paste your own cycle times into the Flow Metrics Calculator.
Setting WIP Limits
- Start with the current average WIP as measured, then lower it gradually.
- Apply the limit to stages of the workflow, not just the whole board, so bottlenecks show up as full columns.
- When a limit is reached, help finish work in progress before starting new work.
- Review after a few weeks using throughput, cycle time, and item age, and adjust.
- Treat blocked items as a signal to remove the blocker, not to start another item.
Self-Assessment Questions
- Do we know our cycle time distribution, not just an average?
- Do we know how many items are in progress at once, and how old they are?
- Do we forecast using percentiles from history?
- Do we limit WIP, and do we act when the limit is reached?
- Do we investigate the longest items, not just the average?
Common Mistakes
Reporting Only the Average
Cycle times are skewed. Use the median and percentiles as well.
WIP Limits Nobody Respects
A limit that is routinely exceeded is decoration. Stop starting, and start finishing.
Measuring Individuals
Flow metrics describe the system. Using them to rank people invites gaming.
Ignoring Waiting Time
Most delay is queues and handoffs. Map the flow and find the longest waits. See Value Stream Mapping.
Flow Metrics and WIP Limits: Frequently Asked Questions
What is the difference between cycle time and lead time?
Cycle time is the time from when work starts on an item to when it is done, while lead time is the time from when the item was requested to when it is delivered, including waiting before work started. Lead time is the customer's experience, and cycle time shows how the team's process performs once work begins.
How does a WIP limit reduce cycle time?
By Little's Law, average cycle time equals average work in progress divided by throughput. If throughput holds steady, fewer items in progress means each finishes sooner. A WIP limit also exposes bottlenecks, because a stage that reaches its limit shows where work is stuck and prompts the team to finish before starting more.
Why use percentiles instead of the average?
Cycle times are usually skewed, with many quick items and a few very slow ones, so the average is pulled up by outliers and hides the spread. A percentile such as the 85th says that 85% of items finish within that time, which makes for a clearer and more honest forecast.
Sources and Further Reading
- John D. C. Little, "A proof for the queuing formula: L = λW," Operations Research, 1961.
- David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business.
- Daniel Vacanti, Actionable Agile Metrics for Predictability.
- Mary and Tom Poppendieck, Lean Software Development.