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.

Cycle time vs. lead time in Kanban

On a Kanban board the two clocks map onto the board itself. Lead time is the customer’s view: it usually runs from when a request is made — the card is created or accepted onto the board — to when it reaches the final column. Cycle time is the team’s view: it runs from when someone pulls the card into the first in-progress column to when it is done. The gap between the two is the time cards spend waiting in the backlog or “Ready” column before anyone starts them.

Kanban also explains why the numbers move. Little’s Law says that, in a stable system, average cycle time equals average work in progress divided by average throughput — so a board carrying too many cards in progress gets slower even when nobody works less. That is why Kanban teams set WIP limits: lowering WIP shortens cycle time, and shrinking the queue in front of the first in-progress column shortens lead time. In Jira, each Kanban board column maps to one or more workflow statuses, so the same status history gives you both numbers.

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.

How do I calculate my cycle time? For a single item, cycle time is the moment it reached Done minus the moment it first moved into In Progress — an issue started on a Monday and finished that Thursday has a cycle time of three days. For a team, average cycle time is the sum of those individual cycle times divided by the number of items finished in the period: five items that took 2, 2, 1, 3 and 3 days average 11 ÷ 5 = 2.2 days. Little’s Law gives a cross-check — average cycle time is roughly average work in progress divided by average throughput. Report a percentile (the 85th is common) alongside the mean, because a few stuck items drag the average up, and state whether you count calendar or working days. In Jira, each issue’s status history supplies both timestamps.

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.

What is the difference between lead time and process time? Lead time is the full elapsed time from the moment work is requested to the moment it is delivered. Process time is only the part of that window in which someone is actively working on the item; everything else is waiting — in the backlog, in a review queue, or for a release. Divide process time by lead time and you get flow efficiency. In most software teams it is low: an item delivered in 20 days with 2 days of hands-on work has a flow efficiency of 10%. That is why shortening lead time is usually about removing queues, not asking people to work faster.

What is the difference between cycle time and flow time? In practice they usually measure the same span, but they come from different vocabularies. “Flow time” belongs to the Flow Framework, where it means the elapsed time from work becoming active to it being delivered. The Kanban Guide does not use the term at all — its four flow measures are work in progress, cycle time, work item age and throughput, and it defines cycle time as the elapsed time between a work item starting and finishing. So when someone contrasts the two, they are almost always contrasting two labels for one clock. What actually differs between teams is the start boundary: if your cycle time begins when an item enters the board rather than when someone picks it up, you are measuring something closer to lead time regardless of what you call it. Name the start and end status whenever you publish the number and the label stops mattering.

---

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 · Change Failure Rate · Deployment Frequency