What is Lead Time?

Lead time tracks how long a unit of work takes to travel from its origin to production. The start point varies by team: some start the clock at first commit, others at ticket creation. DORA, the most widely referenced benchmark in software delivery, starts at commit.

What makes lead time distinct is its scope. Cycle time measures active development. Lead time measures everything, including the days a PR sits unreviewed, the hours a deployment waits for a release window, the week a ticket spends in the backlog before anyone touches it.

A good lead time for elite software teams is under one day. High performers land between one day and one week. Anything beyond a month puts a team in the bottom quartile of DORA benchmarks.

How to measure lead time

The calculation is straightforward:

Lead Time = Development Timestamp - Work Item Start Timestamp

Three data sources feed this: your version control system for commit timestamps, your CI/CD pipeline for deployment events, and your issue tracker for ticket state transitions. Most teams can reconstruct 90 days of lead time from data they already have, without any new tooling.

The trickiest part is agreeing on the start event. Commit-based lead time is the DORA standard and the easiest to automate. Ticket-based lead time is more complete but requires reliable issue tracker timestamps across every workflow stage. Pick one and stick with it. Switching definitions mid-measurement makes trends meaningless.

Lead time vs. cycle time

Cycle time measures how long code takes to go from active development to deployment. Lead time measures the full span from request to delivery, including all the waiting that happens before a developer opens a PR.

A team can have a 2-day cycle time and a 10-day lead time. That 8-day gap sits outside the code itself: requirements queued, PRs waiting, deploys batched weekly. Cycle time tells you how fast your developers work. Lead time tells you how fast your delivery system works. They're both worth tracking, and they diagnose different problems.

Why lead time matters for engineering teams?

Lead time is one of the four DORA metrics because it directly connects engineering behavior to customer outcomes. Teams that ship in hours validate product decisions faster, compound learning across sprints, and absorb far less risk per release than teams shipping in weeks.

A rising lead time with stable cycle time points at organizational friction: approvals, handoffs, or deployment cadence. A rising lead time alongside rising cycle time points at the code itself. The distinction matters because the fix is completely different. One is a process change; the other is a codebase conversation.

Hivel surfaces lead time alongside deployment frequency and PR cycle time so engineering leaders can see where the delivery system breaks, not just that it broke.

See how Hivel tracks lead time across your engineering org →