Delivery Metrics: Cycle Time v Lead Time v Lead Time For Changes

Metrics for engineering delivery productivity include cycle time, lead time, and DORA’s lead time for changes. I don’t like the ambiguity around the wording of the latter two, made worse by many poorly written articles — so here’s an unambiguous (and AWESOME!) article where I tackle the definitions head-on, analyse them, and cover ways to accelerate delivery.

A Simple Worked Example

Let’s outline the difference between cycle time, lead time, and lead time for changes. Here’s my simple worked example:

1. Jira ticket is created in the backlog (“To Do”) on Tuesday, 19th January (at noon)
2. Jira ticket is set to “In Progress” on Monday, 1st February (at noon)
3. First code commit for that ticket is on Wednesday, 3rd February (at noon)
4. PR raised on Thursday, 4th February
5. PR merged on Thursday, 4th February
6. QA completed on Friday, 5th February
7. Production release on Tuesday, 9th February (at noon) — e.g. if the team had defined the “Done” Jira status to represent a completed production release, then that ticket would now be set to “Done”

A comparison of software delivery metrics for my worked example

I want weekends to be excluded, as these are non-working days.

I have included “at noon” on several occasions to simplify the examples. This allows durations to be shown as whole days (with zero hours and minutes). In software metrics, time is typically measured as the elapsed duration, by subtracting timestamps, and is usually shown in days, hours and minutes, i.e. not by counting calendar days (except for skipping non-working days such as weekends!).

Lead Time

Let’s count from Tuesday the 19th January at noon, to Tuesday the 9th February at noon, skipping all of the weekends.

• Total: 16 Working Days, 0 Hours, 0 Minutes
• I defined lead time as starting from when the Jira ticket was in the backlog (“To Do”).
• Although not the focus of this article, an alternative metric called implementation lead time starts later — when the ticket is set to “Ready for Development,” meaning it has been through a refinement process.

Cycle Time

Let’s count from Monday 1st February at noon to Tuesday 9th February at noon, skipping the weekend.

• Total: 7 Working Days, 0 Hours, 0 Minutes (Mon, Tue, Wed, Thu, Fri, Mon, Tue)

DORA’s Lead Time for Changes

DORA defines the metric [1] as:

Time from code commit to successful production deployment.

For practical use, it’s necessary to narrow this definition of commit. By convention in this article, I chose to count from the first commit. Let’s measure from Wednesday 3rd February at noon until the release on Tuesday 9th at noon, skipping the weekend.

• Total: 5 Working Days, 0 Hours, 0 Minutes** **(Wed, Thu, Fri, Mon, Tue)
• Q. Regarding “first commit”, what if the developer batched many commits to their local repo, over multiple days, prior to their first push to the remote repo? Would this negative behaviour gamify the DORA metric once that ticket eventually gets released?
• A. No, it would not, as long as the DORA metrics tool used the ‘Author Date’ git field (when the code was originally committed locally) instead of the ‘Commit Date’ field and let’s assume the “Author Date” field value was not maliciously rewritten by the developer.
• I think DORA (founded in 2014) should have chosen a different terminology, avoiding the ambiguity caused by word overlap, as the “lead time” phrase significantly predates DORA’s “lead time for changes” phrase. This article directly tackles that ambiguity.

A Critique of Lead Time

Personally, I am not a fan of the lead time metric. Many projects I have worked on lack the urgent critical need for a ticket to be raised then immediately worked on. Yes, that happens when there’s an urgent bug to resolve. But, typically, a stable project will build up a backlog, the team will review and prioritise the backlog, and a prioritised selection of Jira tickets will be subsequently worked on.

If a team picks up a low-priority ticket that was in the backlog for one year, then gets through all other work (development, QA, and production release) in just a day, the lead time would be huge — a year and a day!

Conversely, where lead time is useful: what if a customer requested a change, staff raised a Jira ticket for it, and the ticket — despite being important to the customer — sat in the backlog for a long time? Well, that isn’t ideal. Lead time would highlight that inactivity by the team, if the ticket ever got delivered.

Perhaps the compromise would be:

• Highlight lead time only for tickets associated with a customer’s request, or for tickets for a new product feature — e.g. raised by a product manager — where time-to-market is important.
• However, don’t mention lead time for internal tickets. An example is a ticket raised by a developer to “refactor XYZ component”, but addressing that technical debt was not a priority in the understaffed team, hence one year elapsed without action on the ticket. For the given hypothetical ticket and situation, that large amount of time elapsed was absolutely OK, therefore it would be unhelpful to mention the very long lead time for such a ticket.

Accelerating DORA’s Lead Time for Changes

To accelerate DORA’s lead time for changes, it’s all about automation and smaller work units. Teams that have made good use of automated testing and continuous deployment (CI/CD) facilitate code moving from commit to production without waiting for manual QA testing or scheduled release windows.

AI agents that autonomously generate code can reduce the elapsed time in the coding stages of the delivery process. As a disclaimer, the quality of code produced by agentic systems is highly dependent on the quality of the prompts, requirements documents, and guardrails provided by the engineer.

Simultaneously, adopting a trunk-based development model and encouraging small, frequent pull requests could speed up peer reviews and reduce the risk of complex merge conflicts.

Additionally, by incorporating feature flags to decouple deployment from release, code can reach production faster even if the feature isn’t yet “live” for users.

In summary, by streamlining the review process and “shifting left” on security and quality checks, teams can eliminate the idle time that typically worsens the *lead time for changes* metric.

Accelerating Cycle Time

The primary difference is that DORA’s lead time for changes excludes the time between a ticket being set to “In Progress” up until making the first code commit.

As DORA’s lead time for changes is a subset of cycle time, adopting the practices shown in the DORA section above will also improve cycle time.

[1] DORA (2026). “A history of DORA’s software delivery metrics” https://dora.dev/guides/dora-metrics/history/ — refer to “Change lead time”, which is DORA’s synonymous term for lead time for changes.