Lead time is one of those metrics that sounds dead simple until you try to track it consistently across a real project. Then it gets messy fast.
I've seen teams calculate it three different ways in the same sprint retrospective and argue about which number was correct. They were all correct — they were just measuring different things.
So let me break down exactly what lead time is, how to calculate it, and where teams go wrong.
What Lead Time Actually Measures
Lead time is the total time from the moment a request is created to the moment it's delivered. That's it. From "we need this" to "it's done."
It does not start when your team picks up the work. It does not start when development begins. It starts the second the request enters your system — whether that's a Jira ticket, a GitHub issue, a Slack message, or a sticky note on a whiteboard.
This is where most teams get confused. They're measuring cycle time and calling it lead time.
Lead time = time from request created → work delivered
Cycle time = time from work started → work delivered
Cycle time is always shorter than lead time. If you're using cycle time to make promises to stakeholders, you're going to miss deadlines.
The Formula
Lead Time = Delivery Date - Request Date
That's the whole formula. The complexity comes from what you count inside those boundaries.
Working Days vs Calendar Days
This is the first decision you need to make. Do you measure in calendar days or working days?
Calendar days are simpler to track but misleading. A request created Friday afternoon and delivered Monday morning looks like 3 days on a calendar, but your team worked on it for maybe 4 hours.
Working days give you a more accurate picture of actual team capacity. If your team works Monday through Friday, a lead time of 10 working days means two full work weeks which is a meaningful number you can actually plan around.
For most dev teams, working days is the right choice. Use a lead time calculator that handles working days automatically if you don't want to write the logic yourself.
A Practical Example
Say a feature request comes in on Monday January 6th. Your team ships it on Friday January 17th.
Calendar days: 11
Working days: 10
If January 13th was a public holiday, working days drops to 9.
Same delivery, different numbers depending on how you count. Pick one method and stick to it across your whole team the consistency matters more than which method you choose.
Where Teams Go Wrong
Ignoring queue time
The biggest mistake I see is teams only tracking active work time. A ticket that sat in the backlog for 3 weeks before anyone touched it had lead time from the day it was created — not from the day it got assigned.
If your lead times look suspiciously short, check whether you're accidentally measuring cycle time.
Inconsistent start points
Some teams start the clock when a ticket is created. Others start it when it's groomed and added to a sprint. Others start it when it's assigned. Pick one definition, document it, and enforce it.
Not segmenting by work type
A bug fix and a new feature have completely different lead time profiles. If you average them together, the number is meaningless for planning. Track lead time separately for bugs, features, tech debt, and incidents.
What's a Good Lead Time?
It depends entirely on your team and product type. There's no universal benchmark.
That said, here's a rough frame based on what I've seen across different team setups:
Team Type Typical Lead Time
High-performing DevOps teams Less than 1 day
Healthy product teams 1–7 working days
Average enterprise teams 2–4 weeks
Teams with process problems 1–3 months
The DORA metrics research (from the State of DevOps report) uses lead time for changes as one of its four key metrics. Elite performers get changes into production in less than an hour. That's a different measurement context — they're tracking code commit to production, not ticket creation to delivery — but it gives you a sense of what's possible.
Reducing Lead Time
Once you're measuring accurately, reducing lead time usually comes down to three levers:
Reduce queue time. Work sitting in a backlog waiting to be picked up is the biggest lead time killer. Limit work in progress so tickets move faster once they're created.
Reduce handoff friction. Every time work moves between people or teams, it waits. Design reviews, QA, code review, deployment approvals — each one adds days. Streamline the handoffs you can.
Smaller batch sizes. Big features have long lead times. Break them into smaller deliverables that can ship independently. A feature split into five smaller releases will almost always have a lower average lead time than one big release.
Tracking It Without Overthinking
You don't need a fancy tool to start. A simple spreadsheet with ticket ID, created date, delivered date, and a working days formula gets you 80% of the value.
If you want to calculate working days without writing the formula yourself, there are free tools that handle it — including one at CalculatorSpan that lets you factor in custom holidays.
The important thing is to start tracking it consistently. Even rough data collected over two or three sprints will show you patterns you didn't know existed.
Lead time is one of the most honest metrics a dev team can track. It doesn't care about velocity points or story estimates — it just measures the gap between what was asked for and when it arrived. That gap is worth knowing.
If you found this useful, I write about practical productivity tools and calculators at CalculatorSpan.com.
Top comments (0)