Home Product Pulse How Lead time can improve your time-to-market

How Lead time can improve your time-to-market

Author

Date

Category

Wondering how you can use Lead time to improve your time-to-market? We’re happy to announce the release of a new dashboard that allows Engineering teams to optimize their Lead time and Cycle time.

Starting today, in addition to the existing Accelerate dashboards, a new integration with Atlassian’s Jira will give you end-to-end visibility of the performance of your software development process.

With the new dashboard, we’re helping Engineering leaders answer questions they pose on a daily basis when investigating the performance of their teams: What is the velocity of each team? How is the velocity of a team compared to the one of the company? What is stopping us from going faster?

What are Lead time and Cycle time?

Lead time and Cycle time are productivity metrics to help understand if you’re improving the ability to deliver value to customers. They both indicate how long it takes for work to flow through the software development process:

  • Lead time is the time it takes to go from a customer making a request to the request being satisfied. (With pulse, we’re interpreting from Jira the total time elapsed from the creation of work items to their completion.)
  • Cycle time is the time it takes for your team to complete work items once they begin actively working on them.
Definitions of Lead time and Cycle time
Definitions of Lead time and Cycle time

If you are familiar with the Accelerate book, you’ll remember that Lead time for changes is a key metric, which is correlated with both the speed and quality of an engineering team.

“Shorter product delivery lead times are better since they enable faster feedback on what we are building and allow us to course-correct more rapidly. Short lead times are also important when there is a defect or outage, and we need to deliver a fix rapidly and with high confidence.”

Accelerate: The science of lean software and DevOps: Building and scaling high performing technology organizations

Are Lead time and Cycle time different from Lead time for changes?

Until now, Pulse has focused on measuring Lead time for changes, as the time it takes to go from code committed to code successfully running in production. This definition is focused on the delivery part of the software development process and gives a high guarantee of accuracy, by eliminating the variability of the early validation and design phases of software development.

“However, in the context of product development, (…) there are two parts to lead time: the time it takes to design and validate a product or feature, and the time to deliver the feature to customers. In the design part of the lead time, (…) often there is high variability. (…) However, the delivery part of the lead time—the time it takes for work to be implemented, tested, and delivered—is easier to measure and has a lower variability.”

Accelerate: The science of lean software and DevOps: Building and scaling high performing technology organizations

Keep this possible pitfall in mind when integrating your Jira boards: if your board represents an end-to-end process, you’ll get more visibility, but it’s also likely introducing more variability into your measurements.

Is Lead time the same as sprint velocity or any other productivity metric?

Unlike other productivity metrics, Lead time is agnostic to team bias – doesn’t rely on the subjectivity of estimations like sprint velocity – as it focuses on measuring the process instead of the people. As a result, that means that it is an objective metric, and it can be used to compare teams.

Another danger of subjective metrics like activity, lines of code, or sprint velocity can be gamed to display apparent higher performance when it’s not real or is instead hurting the team.

“Lines of code, velocity, and utilization (…) are meaningless as productivity metrics (…) focus on outputs rather than outcomes, (…) on individuals rather than teams.”

Accelerate: The science of lean software and DevOps: Building and scaling high performing technology organizations

The Accelerate researchers found that they could predict poor engineering performance, as measured by Lead time and the Accelerate metrics, based on the amount of busywork taken by engineering teams.

Furthermore, they identified and advocate that maintaining code quality and preventing code smells with static code analysis is one of the key practices to improve a software development process.

“The strongest correlation was seen in the percentage of time spent on rework or unplanned work, including break/fix work, emergency software deployments, and patches, responding to urgent audit documentation requests, and so forth.”

Accelerate: The science of lean software and DevOps: Building and scaling high performing technology organizations

How can I start using Lead time?

What is the velocity of my company?
What is the velocity of my company?

What is the velocity of my company? Adopt Lead time as your organization’s time to market and use it to raise awareness of the importance of investing in DevOps practices and tackling technical debt by showcasing your value and benchmark values.

What is the velocity of each team?
What is the velocity of each team?

What is the velocity of each team? Empower teams with Lead time to make their performance quantifiable and see their progression over time.

Are we achieving our Service Level Objectives for bugs?
Are we achieving our Service Level Objectives for bugs?

Are we achieving our Service Level Objectives for bugs? Use the Lead time of specific work types to eliminate biased perceptions of how long Engineering takes to address defects and give more visibility to your stakeholders.

Would you like to know your Lead time?

Empower your Engineering with the end-to-end visibility of Lead times for teams, epics, and bugs. Connect with Atlassian Jira to enable teams to identify what is impacting their Lead time the most, and how they are contributing to your organization’s time to market.

Get started

Subscribe to our newsletter

To be updated with all the latest news, offers and special announcements.

Recent posts

Becoming a Code Review Master

On September 20th, we did a webinar called Becoming a Code Review Master. Guest speaker Curtis Einsmann, former AWS engineer and...

Announcing our Series B

Hi there.  Today we’re glad to announce that we raised our Series B of $15M led by...

How to tackle technical debt (for teams using Scrum)

Technical debt happens in all software projects, regardless of the programming languages, frameworks, or project methodologies used. It is a common...

Who should care about code coverage

Code coverage tells us what percentage of our code is covered by tests. There are different code coverage types, and a...

9 challenges of managing PRs and how to solve them

Developers have been using Pull Requests to review code on branches before it reaches master for a very long time. However,...