Lead Time vs Cycle Time: What Every Team Lead Should Know

#agile #kanban #productivity

Both measure how long work takes. But they answer different questions and confusing them leads to wrong conclusions about your team.

The short version

Cycle time runs from the moment someone starts working on a ticket to the moment it's done (for the team). It tells you how fast your team moves once they pick something up.

Lead time runs from the moment the request enters the system (a ticket is created, it lands in the backlog) to the "done" point (its in production). It tells you how long the person who asked for a feature has been waiting.

The gap between the two is queue time. If lead time is much longer than cycle time, most of the wait happens before or after anyone is working on it.

That's not a speed problem but a backlog problem.

Why this matters in practice

I lead a software delivery team. When we started measuring cycle time and lead time from our Jira status transitions we found:

Average cycle time: 8 days (not bad)
P85 cycle time: 21 days (problem)
Average lead time: 34 days

The gap between cycle time and lead time was 26 days. Our team was working at a reasonable pace but tickets sat in the backlog or waiting for customer approval for almost a month. No velocity chart would have shown that.

Which number for which conversation

Cycle time is the team's metric. The team can directly influence it — reduce WIP, fix blockers faster, improve reviews.

Lead time is the stakeholder's metric. It's the number they feel. When a product owner asks "why does everything take so long?", they're talking about lead time, not cycle time.

If you only report cycle time, the team looks fast while stakeholders are frustrated. If you only report lead time, the team gets blamed for backlog decisions they don't control.

You need both to have the right conversation with the right people.

How to measure it in Jira

Jira doesn't have a native cycle time or lead time field. Both come from the status transition history (the changelog that records every time a ticket moves from one status to another).

You need to decide:

Which status marks "work started" (cycle time start): usually "In Progress"
Which status marks "request entered the system" (lead time start): usually "Backlog" or "To Do"
Which status marks "done" (shared end point): usually "Done" or "Released"

From there you can compute both metrics per ticket and look at distributions, percentiles, and trends over time.

I built Cylenivo to do exactly this. It reads the full Jira status history and computes cycle time, lead time, throughput, and Monte Carlo forecasts. Its free and runs local. But the concept works regardless of what tool you use.

The takeaway

Stop reporting averages. Start reporting percentiles (P50, P85). And always show both lead time and cycle time because they tell different stories to different people.

If you want to go deeper: