Lead time vs cycle time—two seemingly similar metrics, but they can mean different things to different people.
Lead time and cycle time are metrics that originated in manufacturing. They have been adapted for use in agile software development.
However, using them to measure your dev team’s efficiency may not always lead to your desired results. And it can be difficult to track them without automation.
So which of these two key metrics is the best way to measure the productivity of dev teams? And more importantly, how do you start improving them?
Table of Contents
- What Is Lead Time?
- What Is Cycle Time?
- What Do They Measure?
- Cycle Time vs Lead Time
- How to Improve Lead Time & Cycle Time
- The Best Way to Measure Engineering Efficiency
What Is Lead Time?
Lead time measures the time from when a user story is ready to implement to when that story is ready for delivery. Lead time includes the time used to discuss the user story, the time the request spent waiting in the backlog, and the time someone starts working on the story to when it’s released.
What Is Cycle Time?
Cycle time is the time from a developer’s first commit to when the code is deployed to production. It is one of the 4 key DORA metrics and a subset of lead time.
Cycle time (or lead time for changes) can also be broken into four phases:
- Coding Time (aka fun time): We calculate coding time from first commit to when a pull request or merge request is created.
- Pickup Time: We calculate pickup time from when the PR is created to when the review begins.
- Review Time: We calculate review time from the start of the review to when the code is merged.
- Deploy Time (release time): We calculate deploy time from when the code is merged to when it is released.
Want to learn how to implement custom dev workflow automation to cut code review time by up to 40%? Watch this hands-on workshop to set up the free gitStream tool to automatically:
Classify and route pull requests Add estimated review time to PRs Apply custom rules
gitStream product lead, Ofer Afias, will take you through a live demo of the three core functions when getting started with gitStream workflow automation to scale your team efficiently and improve your developer experience.
What Do They Measure?
Cycle time and lead time are both measurements of engineering efficiency. However, you shouldn’t treat both metrics the same way.
If your team is like every other dev team, you likely have a massive backlog of tickets that you’re never going to work on. Just because someone has a feature idea doesn’t mean it’s important to work on right away…or ever. You don’t want to include those tickets to inaccurately bloat your lead time. And this is why it’s difficult to calculate lead time and standardize it.
However, cycle time can be automatically calculated by correlating data from your Git activity with your issue tracker. Using tools like LinearB, you can even look at it in various ways: at the organization level, by team, by iteration, and even as deeply as a specific branch.
Cycle Time vs. Lead Time
If your goal is a more efficient engineering team, accurately planning iterations and delivering on promises is impossible if your dev team’s cycle time is too long. So, if we had to choose one metric to measure a team’s effectiveness, it would be cycle time vs lead time.
You need to unblock your developers, and it’s not managing the items in the backlog slowing them down this sprint. Inspecting cycle time can show you exactly what’s holding up work in progress this week. And measuring cycle time in four phases takes your understanding of your development pipeline another layer deeper.
That’s not to say that measuring lead time isn’t valuable. It becomes a more useful metric once you’ve ensured your cycle time is low. If you know and can show that your developers are working quickly and agilely but you’re still running into delivery issues, you may have a capacity problem and it’s time to ask for more headcount or revisit priorities.
How to Improve Lead Time & Cycle Time
Since cycle time is a subset of lead time, if you reduce your cycle time, you’re also reducing your lead time, at least a pretty large chunk of it.
LinearB can help you reduce cycle time by showing you which part of the process needs immediate attention. Using our one-click context into cycle time, you can drill down into which stages take the longest or where work is getting bottlenecked.
Based on these insights, you can set team goals for improving the leading indicators that impact cycle time and ultimately lead time. Then tools like LinearB’s developer bot, WorkerB, can automate the improvement within your dev team.
Breaking News! The most effective way to shorten your cycle time is to decrease the average PR size.
The most common reason devs spend too much time coding on one task is that they bit off more than they can chew. It is better to have many smaller PRs that are precisely scoped than a large one that contains many changes.
Not only do small PRs get picked up faster, but they can be reviewed faster and they’ve been linked to higher quality code. Smaller PRs are less likely to create bugs, so developers are happy to merge them quickly.
WorkerB bot can reinforce positive behaviors from your dev team using agreed up on Team Goals around PR size, high-risk work, review depth, pickup time and review time. Your devs can even approve PRs shorter than 5 lines right from Slack or MS Teams.
The Best Way to Measure Engineering Efficiency
Lead time and cycle time are common DevOps metrics to measure engineering efficiency. However, lead time falls short when it comes to unblocking developers and optimizing workflow. That’s why expert tools like LinearB use cycle time as a more accurate measure of a team’s productivity.
But we encourage teams to go beyond measuring indicators of productivity like lead time and cycle time and actually start improving cycle time as well as other DORA metrics.
By using our Engineering Benchmarks, Team Goals, and WorkerB bot, you can automate a developer workflow so your team members can deliver features faster and improve the overall quality of their output.
