DEV Community: calculatorspan

Calculating Lead Time in Working Days

calculatorspan — Wed, 12 Aug 2026 18:21:56 +0000

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.

How to Calculate Lead Time in Project Management (With a Free Calculator)

calculatorspan — Fri, 07 Aug 2026 15:41:01 +0000

Lead time sounds simple. It's just the time between starting something and finishing it, right?

Kind of. But if you've ever missed a deadline because your estimate was off by two days, you already know the gap between "sounds simple" and "actually useful."

Let me break this down properly
what lead time means, how to calculate it, and where most teams go wrong.

What Is Lead Time in Project Management?

Lead time is the total time from when a request or task is initiated to when it's completed and delivered.

It's not just the work time. It includes:

Waiting time before work starts
Active processing time
Review and approval time
Any delays in between

That's the full picture. And that full picture is what you need to plan accurately.

The Basic Lead Time Formula
Lead Time = Delivery Date Order/Request Date

Simple example: If a client requests a deliverable on Monday and you deliver it on Friday, your lead time is 4 days.

But real projects have more moving parts. Here's a more complete version:

Lead Time = Pre-processing Time + Processing Time + Post-processing Time
Pre-processing — time before actual work begins (waiting, queuing, planning)
Processing active work time
Post-processing — review, QA, approval, handoff
A Real Example

Say you're managing a content production workflow:

Client brief received: Monday 9 AM
Writer starts work: Tuesday 10 AM (1 day pre-processing)
Writing completed: Wednesday 5 PM (1.5 days processing)
Review + approval: Thursday 3 PM (0.5 days post-processing)

Total Lead Time = 3 days + 6 hours

If you only counted writing time, you'd have planned for 1.5 days and missed the actual delivery window by double.

Lead Time vs. Cycle Time Don't Mix These Up

This trips up a lot of project managers.

Term What It Measures
Lead Time Full time from request to delivery
Cycle Time Time from when work actually starts to delivery

Cycle time is always shorter than or equal to lead time. If your cycle time is great but lead time is high, your bottleneck is in the waiting not the work itself.

How to Use Lead Time to Improve Planning

Once you're tracking lead time consistently, you can:

Set realistic deadlines base them on historical averages, not optimistic estimates
Identify bottlenecks high pre-processing time means your intake or prioritization process needs work
Improve client communication tell clients actual lead times, not best-case times
Reduce waste every day of unnecessary waiting is a day of delayed delivery

In my experience, most teams underestimate lead time by 30–40% because they only account for active work time.

Calculate It Without the Headache

Doing this manually gets tedious fast especially across multiple tasks or team members.

I built a free Lead Time Calculator on calculatorspan.com that handles the math instantly. Plug in your start date, end date, and working hours it gives you the exact lead time breakdown.

👉 Try the Lead Time Calculator calculatorspan.com

No signup. No fluff. Just the number you need.

Quick Tips Before You Go
Always measure lead time in working days, not calendar days, for accuracy
Track lead time per task type design tasks and dev tasks have different baselines
Review your average lead time monthly and look for trends
If lead time is increasing over time, your team capacity or intake process has a problem

Lead time is one of those metrics that looks basic but reveals a lot when you actually start tracking it. Start measuring it on your next project even informally and you'll immediately make better commitments.