Lead Time and Cycle Time
The two most important metrics for understanding how long work takes.
1Definitions
These terms are often confused. Here are precise definitions:
Lead Time: The total time from when work is requested until it's delivered.
- Clock starts: When the customer/stakeholder requests the work
- Clock stops: When the customer receives the value
Cycle Time: The time from when work starts until it's finished.
- Clock starts: When someone begins working on the item
- Clock stops: When the work is complete
The relationship:
Lead Time = Cycle Time + Queue Time (waiting before work starts)
Lead time is what customers care about. Cycle time is what the team controls directly. Both matter.
Terminology Confusion
Different communities define these differently. Kanban uses the definitions above. Always clarify with your team what you mean.
2Why Lead Time Matters
Lead time is the customer's experience. They asked for something—how long until they got it?
Short lead times mean:
- Faster feedback on ideas
- Ability to respond to market changes
- Higher customer satisfaction
- Competitive advantage
Measuring lead time reveals:
- The full cost of queues (often 80%+ of lead time is waiting)
- Where the system adds delay
- Whether improvements are working
Most teams dramatically underestimate their lead time because they only see cycle time. "The feature took 3 days to build" ignores the 3 weeks it sat in the backlog and the week it waited for deployment.
3Why Cycle Time Matters
Cycle time is the team's internal efficiency. How quickly can we complete work once we start?
Short cycle times mean:
- Less work-in-progress at once
- Faster feedback loops
- Easier context switching
- More predictable delivery
Measuring cycle time reveals:
- How much variation exists (a little or a lot?)
- Which types of work take longer
- Whether the team is getting faster or slower
The variation matters as much as the average. A team with 5-day average but 2-20 day range is less predictable than one with 7-day average and 5-10 day range.
Team's cycle time ranges from 3-5 days for most items. They can confidently say 'we'll have this done by Friday' on Monday.
Team's cycle time ranges from 1-30 days. Nobody knows when anything will be done. Promises are unreliable. Planning is fiction.
4How to Measure
Manual tracking (simple start):
- Record the date work enters "In Progress"
- Record the date work reaches "Done"
- Calculate the difference
Digital tools: Most Kanban tools track this automatically:
- Jira: Time in Status report
- Linear: Cycle time analytics
- Trello: With plugins
- Azure DevOps: Cycle time charts
What to track:
- Individual item times (for trends and analysis)
- Percentiles (50th, 85th, 95th) rather than just averages
- Breakdown by work type (bugs faster than features?)
- Trend over time (getting better or worse?)
Avoid:
- Using averages alone (they hide variation)
- Including weekends in calculations without thought
- Mixing different work types into one metric
5Using the Data
Once you have cycle time data, use it for:
Forecasting: "85% of items like this complete within 8 days. I'm comfortable saying we'll have it by next Friday."
Identifying problems: "This item has been in progress for 12 days. Our 85th percentile is 8 days. Something's wrong—let's investigate."
Improvement validation: "Last quarter our median cycle time was 5 days. This quarter it's 4 days. Our process changes are working."
Right-sizing: "Large features have 3x the cycle time variance of small ones. Let's break work into smaller pieces."
The insight: Cycle time isn't just a report—it's a tool for making better decisions in the moment.
Focus on the 85th percentile, not the average. 'Most items complete in 5 days or less' is more useful than 'average is 5 days' because it accounts for variation.
- Lead time = customer experience; Cycle time = team efficiency
- Lead time includes queue time, cycle time doesn't
- Percentiles (especially 85th) are more useful than averages
- Use metrics for forecasting, problem detection, and improvement validation