Throughput vs Cycle Time: Reading Both Without Fooling Yourself
By Sebastiaan Jansen · · 8 min read
Throughput vs cycle time compares two measurements. Throughput is how many items a team finishes in a period. Cycle time is how long one item spends between the start and finish points you agreed on. A team can raise throughput while cycle time gets worse, or shorten cycle time while the number finished stays flat.
You need both. One tells you how much work left the system, the other how long a single item was inside it.
What each number is counting
Throughput is a completion count. Pick a window, usually a week, and count the items that reached done. Eight tickets this week is a throughput of eight. The unit is items per period, not hours.
Cycle time is a duration for one item. The clock starts when work begins under your definition (often when a ticket enters an active column) and stops when it meets your definition of done. A ticket that entered development on Monday and shipped on Thursday has a cycle time of three working days, or four calendar days. Pick one clock, say which one it is, and stick with it. The formula and usual ranges are in Cycle Time in Software Development: Definition, Formula and Benchmarks.
Neither number includes the wait before work is allowed to start. That wait belongs to lead time. A request that sat in a backlog for three weeks and then took four days to build has a cycle time of four days and a lead time of about three and a half weeks. Cycle Time vs Lead Time: The Difference and Why Both Matter covers what goes wrong when teams mix those clocks.
Where "throughput time" confuses the labels
Manufacturing writing sometimes uses "throughput time" for how long a unit spends in the process. That is a duration, so it behaves like cycle time or lead time, depending on where the clock starts. Software teams more often say "throughput" and mean a count of finished items.
That clash is why the search phrases disagree. The query cycle time vs throughput time compares two durations only if "throughput time" means elapsed time in the line. The query throughput time vs cycle time is the same pair of clocks with the words swapped. If your dashboard uses "throughput" for a weekly count, don't read that count as a time. Write the unit next to the number: items per week, or days per item.
Throughput vs cycle time on one board
The two numbers use different units, and each one can mislead you in its own way.
| Throughput | Cycle time | |
|---|---|---|
| Unit | Items finished per week (or day, or sprint) | Elapsed time per item |
| Question it answers | How much did we finish? | How long did this item take once started? |
| Typical chart | Weekly counts | A scatter of item ages, plus a percentile |
| Moves when | More items reach done, or fewer do | Started items take a longer or shorter path |
| Easy to fool yourself with | Counting a one-line fix as equal to a migration | Letting one slow outlier set the "typical" time |
| Does not tell you | Whether any single item was predictable | Whether the team finished enough work |
A weekly update might read: "We finished 11 items. Half took 4 days or less, and 85% took 9 days or less." The first sentence is throughput. The second is cycle time at two percentiles. An average would hide the slow tail, and the slow tail is what stakeholders feel.
Why one can improve while the other gets worse
Both metrics read from the same board and the same done column, but different things drive them.
Shorter cycle time, same throughput. Smaller tickets, or fewer items in progress, can drop the median from six days to three while weekly throughput stays at ten. Looking at cycle time alone, the team seems twice as fast. The scope shipped per month did not double.
Higher throughput, longer cycle time. Starting more work in parallel lifts throughput for a few weeks, because items already in progress land together. Then every new item waits, cycle time stretches, and throughput falls back. The spike was just work in progress being flushed out. WIP Limits: How to Set Them and What Changes When You Do stops that from becoming the norm.
Same team, different mix. A week of bug fixes can show throughput of 20 and a median cycle time of one day. A migration week can show throughput of 2 and a cycle time of 15 days. Nobody sped up and then collapsed; the work changed. Split the count by type before you compare periods.
Little's Law says that, in a stable system, average WIP equals average throughput times average cycle time, in matching units. If arrivals stay steady, cutting items in progress lowers average cycle time. The law does not promise higher throughput. It only says how the three quantities balance.
A worked example
This is an illustration, not a benchmark. Cycle time is calendar days from "build" to "done." Throughput is items entering done in a Monday-Sunday week.
| Week | Finished (throughput) | Median cycle time | 85th percentile | Average WIP |
|---|---|---|---|---|
| 1 | 9 | 5 days | 11 days | 14 |
| 2 | 8 | 5 days | 12 days | 15 |
| 3 | 11 | 4 days | 10 days | 13 |
| 4 | 10 | 6 days | 16 days | 18 |
| 5 | 7 | 8 days | 18 days | 20 |
| 6 | 8 | 7 days | 15 days | 17 |
| 7 | 10 | 5 days | 11 days | 14 |
| 8 | 9 | 5 days | 10 days | 13 |
Weeks 1 to 3 sit near 9 or 10 finished, with a median around 5 days. In week 4 the team pulls four extra tickets into build. Throughput is still 10, so a review that only looks at throughput says nothing changed. But the 85th percentile has already jumped to 16, and those extra starts are still on the board.
Week 5 finishes 7, and the same review now says the team slowed down. Nobody left. Those items were stuck behind the week-4 pile. In weeks 7 and 8 the team clears what is open and refuses new starts above the old level. Throughput returns to about 9 or 10, the median to 5 days, and the 85th percentile to about 10 or 11.
A forecast built from week 5 alone pads everything. One built from week 3 misses the slow tail. Taken together, the weeks show about 9 items a week, WIP near 14, and a slow item usually done inside a week and a half. In week 4, though, the people waiting felt 16 days, not the median of 6.
How to keep the comparison honest
Use one start column and one done column for both metrics. If throughput counts a merge, cycle time stops at merge too. If cycle time stops at "in production" while throughput counts at "code complete," you are describing two different systems.
Keep item type visible. Product work gets one pair of numbers; incidents and chores get another. Combined throughput can inform staffing, but it should not be the only line in a planning review.
Use percentiles, not the mean. The 50th is the typical item. The 85th is the slow item you should still expect. A ticket that waited 30 days on a vendor pulls the mean up, and any commitment built on that mean inherits the delay.
Judge throughput across four to eight weeks. A single week swings when a freeze ends or three people finish on Friday. With five finished items, one extra ticket is a 20% move, and most of that is noise.
When the metrics disagree, look at WIP before you look at individual performance. How to Read a Cumulative Flow Diagram (With Examples) shows arrivals, starts, and finishes as bands. The table above squeezes all of that into one WIP column.
Reading throughput vs cycle time this way takes longer than glancing at a dashboard tile. In return, you can take the result into planning and not have to walk it back a week later.
What to change, and what to leave alone
- Cycle time long, WIP high, throughput fine: finish the oldest items before pulling new ones.
- Throughput too low for commitments, cycle time already short: the gap is scope, staffing, or item size. Smaller tickets raise the count only when the same scope ships as more items.
- Both worse after a mix change, such as a migration quarter: split the metrics and replan from the new mix.
- Both better, WIP stable: keep the policy. Add a project only when it is worth disturbing a history you can forecast from.
Dates should come from the run of throughput, not from one cycle time multiplied by the backlog. If the last eight weeks each finished 7 to 11 similar items, 40 remaining items still take several weeks, and that is before unplanned arrivals. A Monte Carlo draw over that history gives you a range. Multiplying one cycle time by forty looks precise but isn't, because items overlap and the slow tail is not the median. Monte Carlo Forecasting for Software Delivery Dates walks through how to get that range.
People outside the team need the date range, not both charts. A "two-week sprint" label means little when the 85th percentile is already 11 days. Give marketing a range marketing can plan a launch against, built from this reading.
Falrow computes the pair from tickets the team already moves: cycle time percentiles, plus cumulative flow and a Monte Carlo forecast from throughput history (2,000 runs). That makes a flat count next to rising item age easy to spot. A spreadsheet can do the same job from start and done dates. Either way, keep the count and the duration apart.
FAQ
Is throughput the same thing as cycle time?
No. Throughput is how many items you finish in a period. Cycle time is how long one item takes from your start point to your done point. They share a done column but answer different questions. Calling either one "team speed" throws away the unit.
Which is more important, throughput or cycle time?
It depends on the question. For a date across a backlog, throughput over several weeks is the direct input. For one request already in progress, use cycle time percentiles. A shorter cycle time can just mean smaller pieces at the same weekly rate.
Can cycle time go down while throughput stays flat?
Yes. Smaller tickets, less rework, and lower WIP often cut cycle time without adding finished scope. That is a real gain in responsiveness, but it does not prove the team can absorb a larger roadmap. Check that items are comparable before you call the system faster.
How many weeks of data do you need?
Four to eight recent weeks is enough to see whether the two numbers usually move together, as long as the mix of work did not flip halfway through. One week can show a stuck review column, but it is not enough to claim a process change worked. If WIP changed sharply, read the weeks before and after as separate periods.