Lead Time for Software Delivery
Lead time measures the velocity of an engineering organization in delivering software — from idea to production. Shorter lead times mean shorter turnaround times for new feature requests, incident resolutions, bug fixes etc. In this blog post, learn more about lead time and cycle time for software delivery, and how to measure them.
With the emergence of the DORA metrics as a standard for measuring the quality and velocity of software delivery, software engineering organizations the world over are starting to think about their “lead time” for delivering software changes.
What is lead time?
Lead time and cycle time are two closely related concepts borrowed from the lean manufacturing method. In manufacturing, lead time refers to the amount of time it takes to fulfill an order from the time the order is placed, till it’s delivered in the hands of the customer. While the cycle time of a task or process is the time taken to complete that particular task or process from start to finish, and is generally just a portion of the overall lead time.
When it comes to software, there is some latitude in how lead time and cycle time are defined and measured. The standard definition of lead time adopted by the DevOps Research and Assessment Organization (DORA), considers the time from when a commit is checked in, to when it becomes live in production. Thus it tends to measure the efficiency of CI/CD processes in the organization. However one can take a broader view on this, measuring the end-to-end time for software delivery:
Lead Time: The lead time of a software change is the time it takes to deliver the change — from idea to production. The change could be as granular as makes sense. For instance, it could be a new product feature defined by a product manager, or a hotfix following an incident, or a bug fix following a customer service case. Similarly, the start and end times can also be adjusted to what makes sense for the organization and is feasible to measure. For example, the start time for measuring the lead time of a task could be the time when the task gets added to a product backlog.
Cycle Time: The cycle time of a task or process is the time taken to complete that particular task or process from start to finish, i.e., from when it first goes from being "in progress" to when it is "done". This is typically just a portion of the overall lead time.
Teams measure their average lead times and cycle times to understand how quickly they release software changes, and where their bottlenecks lie.
Why does lead time matter?
Lead time measures the velocity of an engineering organization in delivering software — from idea to production. Shorter lead times mean shorter turnaround times for new feature requests, incident resolutions, bug fixes etc. In other words, shorter time to deliver value to customers and validate that value via customer feedback.
Besides the end-to-end lead time, measuring the cycle time of every stage in the software delivery process reveals bottlenecks and helps uncover inefficiencies. For example,
- Code reviews may be taking too long because review load may not be evenly spread out across the team.
- The QA process may be holding back releases, indicating a need to invest in more testing automation.
- Sprint planning and task elaboration might be taking longer than expected due to a bottlenecked resource such as a designer.
- Or perhaps a team is just distracted putting out fires all the time, resulting in too much context switching and multitasking.
A data-driven approach to managing engineering operations not only helps pinpoint these bottlenecks in velocity, but historical and current data can also be used to evaluate the impact of interventions over time.
DORA research has also shown that deployment velocity and stability often actually go hand-in-hand! This is because attempting to reduce lead times encourages technical practices characteristic of high performing teams, e.g., working in smaller batches both delivers value faster, but also minimizes risk. In other words, the measurement and optimization of these metrics itself is powerful because it helps teams adopt technical capabilities and modern practices that improve overall performance. Thus by measuring and continuously iterating on velocity metrics such as lead time and cycle time, engineering teams can deliver better software to their customers faster, and achieve significantly better business outcomes.
So how do you measure lead time?
Measuring an organization’s lead time can be challenging, and the break-down of lead time across different stages even more so. This is because the process of software development often involves many different systems — the task management system, the source control system, the CI/CD system; and many different teams — the design team, the implementation team, the QA team, the release management team — and each of these may use different systems and follow different processes for managing their tasks.
Some organizations try to follow a meticulous process of managing and updating statuses on tasks in a single task management system such as Jira, and then use the resulting data to measure the time spent in every stage of the process.
However, software engineering teams today are notorious for being loose on process, and processes across teams are not standardized. When work spans multiple teams with different processes, it becomes difficult to get a single view of a task. Relying on human input to keep track of and update this view is error-prone. Moreover, excessive process can significantly slow down teams. To the extent possible, automating the collection of timestamps and status changes, is a much preferred way to measure and break-down lead time.
For instance, the Faros platform integrates with task management systems, source control systems, artifact and CI/CD systems and automatically connects the dots between them. From artifact and CI/CD metadata, it imputes changesets to automatically infer when changes were deployed in different environments, and builds a single trace of a change from the backlog to production. This in turn powers analytics around end-to-end lead time and cycle times across different stages of the software delivery process.
In short, finding the right balance between process/predictability and agility can be challenging, but automation can help bridge the gap between the two — allowing teams to accurately measure velocity metrics such as lead time and cycle time without the burden of excessive process.
See Faros AI in Action
Our DORA metrics dashboards are field-proven to generate accurate, granular, and correctly attributed metrics, even in the most complex environments. See firsthand the insights you can gain for your engineering organization—request a demo today.
Shubha Nabar
Shubha Nabar is the Co-founder of Faros AI. Prior to Faros AI, she was part of the founding team of the Einstein machine learning platform at Salesforce and built data products and data science teams at LinkedIn and Microsoft.
Read the report to uncover what’s holding teams back—and how to fix it fast.
What to measure and why it matters.
And the 5 critical practices that turn data into impact.
More articles for you
Engineering Leadership Framework: Vision, Strategy & Execution Guide
.webp)
What is Data-Driven Engineering? The Complete Guide
Engineering Team Metrics: How Software Engineering Culture Shapes Performance
See what Faros AI can do for you!
Global enterprises trust Faros AI to accelerate their engineering operations. Give us 30 minutes of your time and see it for yourself.