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.
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
How is Lead time related to Code quality?
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? 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? 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? 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.
Does this seem interesting? Get started here.
Top comments (0)