Calculator inputs
Enter average hours for one software work item. Use realistic queue, blocker, and rework values for better optimization estimates.
Example data table
Use these sample values as a benchmark when estimating stage delays and improvement potential across typical delivery workflows.
| Scenario | Dev hrs | Review hrs | QA hrs | Wait hrs | Rework % | Current lead hrs | Optimized lead hrs |
|---|---|---|---|---|---|---|---|
| Small bug fix | 6 | 1.5 | 2 | 5 | 6 | 15.3 | 11.9 |
| Medium feature | 18 | 4 | 8 | 16 | 10 | 48.4 | 35.6 |
| API enhancement | 24 | 5 | 9 | 18 | 12 | 58.8 | 42.1 |
| Cross-team release | 28 | 6 | 10 | 26 | 15 | 74.4 | 53.2 |
| High-risk refactor | 36 | 8 | 14 | 30 | 18 | 95.1 | 67.8 |
Formula used
1) Current lead time
Current Lead Time = Value-Added Work + Waiting Time + Rework Hours + Context Loss Hours
2) Value-added work
Value-Added Work = Development + Review + QA + Deployment
3) Waiting time
Waiting Time = Backlog Queue + Review Queue + QA Queue + Blockers + Handoffs
4) Rework and context loss
Rework Hours = Value-Added Work × Rework Rate
Context Loss Hours = Value-Added Work × Context Switching Rate
5) Optimized lead time
Optimized Lead Time = Optimized Work + Optimized Wait + Optimized Rework + Optimized Context Loss
6) Improvement percentage
Improvement % = (Current Lead Time − Optimized Lead Time) ÷ Current Lead Time × 100
This model is useful for comparing scenarios, prioritizing bottlenecks, and estimating how automation, planning, review, and QA changes affect delivery speed.
How to use this calculator
- Enter the average hours spent waiting, building, reviewing, testing, and deploying one software item.
- Add blocker, handoff, rework, and context switching values to reflect real process friction.
- Estimate improvement percentages for automation, review, QA, blockers, and planning readiness.
- Set working hours, period length, delivery volume, and your target lead time.
- Submit the form to view the result directly under the header and above the form.
- Use the summary, bottleneck insight, and exports to compare future process improvement plans.
Frequently asked questions
What is lead time in software development?
Lead time measures the total elapsed time from work intake to production delivery. It includes active work, waiting, rework, approvals, testing, and release delays, not just coding time.
How is this different from cycle time?
Cycle time usually starts when active work begins. Lead time starts earlier, covering backlog wait, handoffs, reviews, blockers, and other delays before customers receive value.
Why include rework in the model?
Rework adds hidden delay because completed work must be corrected, retested, or reapproved. Even small rework percentages can materially increase total delivery time.
Why does context switching matter?
Frequent interruptions reduce focus and extend completion time. Modeling context loss helps teams understand how multitasking, urgent requests, and fragmented ownership slow delivery.
What counts as automation gain?
Automation gain represents time saved through scripts, pipelines, templates, checks, or deployment tooling. It generally reduces direct effort and often lowers rework as well.
Should I enter data per item or per sprint?
Enter stage times for one typical work item. Sprint volume and sprint length are separate inputs used only to estimate throughput before and after optimization.
How should I choose the target lead time?
Use a target tied to service goals, release expectations, or customer commitments. The target should be achievable, measurable, and aligned with your team’s operating model.
Can this calculator replace process analysis?
No. It is a decision-support tool for scenario testing. Teams should still validate assumptions with real workflow data, retrospectives, and value stream mapping.