Key Takeaways
- Cycle time measures active work from In Progress to Done, lead time measures the whole wait from request to delivery, and DORA’s lead time for changes measures only commit to production.
- The three clocks tell different stories: in one example a Jira issue shows a 12-day lead time but only a 3-day cycle time and a 2-day lead time for changes.
- A long lead time with a short cycle time is a prioritization and queue problem, since work sits in the backlog before anyone starts it, while a long cycle time points at reviews, testing, and hand-offs.
- Optimizing cycle time when the real problem is backlog wait spends effort in the wrong place, so track more than one clock and always say which one you started.
- Time in Status, Cycle Time & Lead Time Reports charts both Cycle Time and Lead Time from your Jira workflow with start and end statuses you define, so each metric measures exactly the clock you mean.
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.
What is the difference between cycle time and lead time in Jira? In Jira terms, lead time runs from issue created to Done, while cycle time runs from the first move into In Progress to Done. Both are computed from your workflow’s status history, and the start and end statuses you pick define which clock you are measuring.
What are the differences between lead time, cycle time, and throughput? Lead time and cycle time both measure duration — how long a single item takes, from request to delivery and from start to Done respectively. Throughput measures volume: how many items the team finishes in a period. Duration answers “how long does one change wait?”; throughput answers “how much does the system deliver?” Read them together, because they can move in opposite directions — a team can cut cycle time while throughput falls simply by working on fewer items at once. See throughput in Jira.
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.
Is takt time the same as cycle time? No. Takt time is a manufacturing pace — available production time divided by units of customer demand. Cycle time in software measures how long one work item spends in active progress. Takt time rarely transfers cleanly to software delivery, where demand and item sizes vary; cycle time and lead time are the clocks that do.
What is the difference between cycle time and process time? Process time (sometimes called touch time or work time) counts only the hours someone is actively working on an item. Cycle time counts the whole elapsed window from In Progress to Done — including the time the item sits waiting for a review, a test environment or a hand-off. The gap between the two is queue time, and in most software teams it is the larger share: an item with two days of process time and a two-week cycle time is a waiting problem, not a working problem. Jira status history gives you cycle time directly; process time needs time logging or an estimate.
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
