Cycle Time for Engineering Teams: Median, P85 and the Long Tail

What cycle time is

Cycle time is the elapsed time from when work starts (first moves into an in-progress status) until it is done. Lead time is measured from when the item was created (or requested). Lead time includes backlog waiting; cycle time does not.

Why it matters

Short, predictable cycle times make sprint commitments reliable: if most items finish within six days, anything started in the second half of a two-week sprint is at risk and everyone can see it. Long or highly variable cycle times explain carryover better than any velocity chart.

How to calculate it

Cycle time needs the timestamp when work started. That comes from the status change history (Jira's changelog), not from the issue fields in a CSV export. Jira's optional "Status Category Changed" field records only the latest category change, so for a completed issue it is the done date, not the start date.

Report the distribution, not the average:

• Median (P50) — the typical item.
• P75 / P85 — a planning figure: "most items finish within N days".
• P90 — the long tail that causes carryover.
• Outliers — items beyond Q3 + 1.5×IQR; each deserves a look.

P85 cycle time = the value that 85% of completed items finished within

Time per stage

Summing the time each issue spent in development, review, QA and release shows where the time goes. This also requires status history. If you only have a CSV, do not estimate it — use lead time and state clearly that it includes backlog wait.

How to interpret it

• A wide gap between median and P90 means a few items take far longer than the rest — usually large, blocked or unclear items.
• Most of the time in wait stages (review, ready-for-QA, ready-for-release) means process, not engineering effort, dominates.
• Cycle time rising while throughput is flat often means more work is being started at once (see aging WIP).
• Compare the P85 with the sprint length. If P85 is 12 days in a 10-working-day sprint, much of the plan cannot finish unless it starts on day one.

Cycle time, WIP and throughput are linked

Little's Law describes the relationship for a stable system: average cycle time equals average work in progress divided by average throughput. If a team finishes about 15 items per week and has 45 items in progress, items will take about three weeks on average — regardless of how hard anyone works. The practical consequence is that the fastest way to shorten cycle time is usually to start fewer things at once, not to work faster.

Common mistakes

• Using averages. A few very long items drag the mean far from the typical experience.
• Calling lead time "cycle time". Created → resolved includes weeks of backlog waiting.
• Inferring stage times from current status. Impossible without history.
• Excluding the outliers. They are the most informative items.
• Using cycle time to compare individuals. It measures the system.

What engineering managers can do

1. Limit work in progress; fewer items at once means each finishes faster.
2. Attack the biggest wait stage first — it is usually cheaper than speeding up active work.
3. Split items whose expected cycle time exceeds half the sprint.
4. Use P85 when answering "when will it be done?" instead of a single-point estimate.
5. Export the changelog so you can see stage-level time. Many teams discover most of their cycle time is waiting.

Example

A team's median cycle time is 6 days, P85 is 12 and P90 is 15. Stage medians show development at 3.2 days, review at 1.9, QA at 0.2 and ready-for-release at 4.0. The longest single contributor is waiting for a release — invisible in a CSV export, and fixable without writing more code faster.

The team moves from two scheduled releases a week to releasing whenever QA passes. Two sprints later the release stage median is under a day, overall median cycle time falls to about 3.5 days, and — because more work now finishes inside the sprint — carryover drops too. Nothing about how the team writes code changed.

How this tool helps

See it on your own data in the Cycle time report.

The cycle time view shows median, P75, P90 and outliers, and per-stage timing when you import a change-history file. With a CSV only, it shows lead time and explains exactly what is missing — it never invents stage durations.

Frequently asked questions

What is the difference between cycle time and lead time?

Lead time starts when an item is created; cycle time starts when work begins. Lead time includes backlog waiting, so it is always at least as long as cycle time.

Can I calculate cycle time from a Jira CSV export?

Not accurately. A standard export has created and resolved dates (lead time) but not when work started. Cycle time and time per stage need the status change history.

Why use percentiles instead of the average?

Cycle time distributions have long tails. Percentiles describe what most items experience and how bad the tail is; the average describes neither.

Related guides

• Aging WIP

  How to measure the age of in-progress work, choose useful age buckets, compare against historical cycle time, and act on old work without turning it into blame.

• Engineering bottlenecks

  How to find delivery bottlenecks in an engineering workflow using queue size and time-in-stage, why arbitrary red/amber/green thresholds mislead, and what to do once you find the constraint.

• Software delivery metrics

  A leader's guide to software delivery metrics: flow metrics, sprint predictability and DORA, what each can and cannot tell you, and how to avoid turning metrics into targets.

• Capacity planning

  Plan sprint commitments against historical throughput ranges instead of optimistic capacity math. Include existing WIP and typical scope growth, and communicate risk honestly.