Cycle time measures how long active work takes; lead time measures the whole wait from request to delivery; and DORA’s lead time for changes is a third, narrower measure — from code commit to production. Mixing them up is one of the most common mistakes in delivery metrics, and it leads teams to “fix” the wrong part of their process. Here’s the clear distinction, with a worked example.

Three terms, three questions

• Lead time answers “how long from when a customer asked to when they got it?” — it starts when a request is created and ends when it’s delivered.
• Cycle time answers “how long once we actually started?” — it starts when work goes In Progress and ends at Done.
• Lead time for changes answers “how long from commit to production?” — the DORA delivery metric. See DORA metrics in Jira.

A worked example

Imagine a Jira issue created on Day 0. It waits in the backlog until Day 8, when a developer moves it to In Progress. It reaches Done on Day 11, and the change is deployed to production on Day 12.

• Lead time = Day 0 to Day 12 = 12 days.
• Cycle time = Day 8 to Day 11 = 3 days.
• Lead time for changes = commit (say Day 10) to production (Day 12) = 2 days.

All three are “true,” but they tell different stories. The 12-day lead time is dominated by backlog wait, not engineering speed. If you only looked at cycle time, you’d conclude the team is fast — and miss that customers wait nearly two weeks.

Why the difference matters

Each metric points to a different lever. A long lead time with a short cycle time is a prioritisation and queue problem — work sits before anyone starts it. A long cycle time points at the execution process — reviews, testing, hand-offs. Optimising cycle time when your real problem is backlog wait is effort spent in the wrong place.

Which should you track?

Track more than one. Cycle time is the best day-to-day signal of process health for a delivery team. Lead time reflects the customer’s actual experience of waiting. Lead time for changes is the one to use when you’re benchmarking delivery performance against DORA. The mistake isn’t choosing one — it’s calling whichever you measure “lead time” without saying which clock you started.

Measuring cycle time and lead time in Jira

Our app, Time in Status, Cycle Time & Lead Time Reports, charts both Cycle Time and Lead Time straight from your Jira workflow — you define the start and end statuses, so each metric measures exactly the clock you mean. Break results down by epic, label or fix version, export to CSV, and let the built-in Rovo AI agent explain shifts in plain language. DORA’s four keys are on our roadmap.

FAQ

Is cycle time part of lead time? Yes — cycle time is the active-work slice inside the larger lead-time window.

Which is better, cycle time or lead time? Neither; they answer different questions. Use cycle time for process health and lead time for the customer’s wait.

How does this relate to DORA? DORA’s delivery-speed metric is lead time for changes (commit to production), which is narrower than both — see the DORA guide.

---

Measure the right clock in Jira: Try the app free · Learn more on divim.io

Part of our DORA series: DORA Metrics in Jira · Lead Time for Changes