Lead Time: Releasing Software to Customers Faster

What Is Lead Time?

At FloQast, we define lead time as the total time a ticket spends from “In Progress” to “Done.”

Put another way, “Once we begin work on a ticket in a sprint, how long does it take us to get those changes deployed to production and provide actual value to a customer?”

How Do We Track Lead Time?

We track our lead time at various intervals – 14 days, 30 days, and three months – in a google sheet like this:

All of this data is pulled from Jira via the “Control Chart” report. We use a “lead time” quick filter to ensure we track lead time only for appropriate tickets; For example, we exclude any SPIKE tickets from lead time or any other task tickets that don’t actually result in application code being deployed to production.

Why Do We Care About It?

Alright, so we know what lead time is and how to track it, but so what? As with most initiatives in software development, they don’t gain traction if the responsible parties don’t understand why they are doing what they are. Well, let’s take a look at a few great reasons to care about lead time.

Having a low lead time enables us to:

Address high-priority defects quickly

• If our development and release process is free of bottlenecks, we will be able to address defects quickly and keep customers happy.

Practice continuous delivery and have a tight feedback loop with customers

• The full benefit of continuous delivery is outside the scope of this post, but put simply, this allows us to be highly agile with respect to our roadmap. If we can get code shipped more quickly, then we can get customer feedback more quickly and therefore make micro-corrections in the roadmap as needed.

Be a high-performing software company

• Research from the book Accelerate shows that high-performing software organizations have a low lead time.
  

Note: The definition of lead time in this graphic is “time from code committed to deployed,” which our definition at FloQast encompasses.

Changing the Behaviors of Teams

Striving for a low lead time also encourages other valuable behaviors in our teams, such as:

Emphasizing small batch sizes

It makes sense that smaller scope releases go hand in hand with a low lead time; they are easier and quicker to develop and test.

Focusing on small batch sizes itself is helpful for a number of reasons:

• Smaller scope = less risk of regression per release (aka low “Change Failure Rate” in the above graphic)
• If a defect does come up, it’s much easier to track down the issue in a 5-file PR than a 50-file change across 4 repos
• Again if a defect does come up, it will block less code from shipping than if it was part of a big PR/release.
  Imagine we have two features we’d like to release, feature A and feature B, and let’s say we decide to tackle both features in a single ticket. Now let’s assume that feature A is riddled with bugs but feature B works perfectly. At every stage of development (in progress, code review, QE Testing etc) every time we find an issue with feature A we are also delaying feature B from being released! Had we separated these out into smaller batches and developed in parallel, feature B could’ve been shipped and provided value while we worked out issues with feature A.

Predictability

Generally speaking, a group of five 1-point tickets can be delivered far more predictably than a single 5-point ticket. This is yet another positive side effect of having small batch sizes.

More work can be done in parallel, so the development of features takes less time from start to finish.

Critical thinking about our process

At FloQast, our engineers are expected to think beyond just the code. While the Engineer Manager is responsible for the process, the entire team (including the EM) is part of improving our process.

If we are consistently thinking about how to achieve low lead time, we will also continuously improve our process along the way.

Swarming mentality

Wait… What is that?
Explaining “swarming” and all its benefits is outside the scope of this post – and if you’re a developer, I know you are an expert at Googling – but in short, this is a trait of high-performing agile software teams wherein they consistently work together to achieve a common goal (e.g. the sprint goal). For example, when a developer is freed up in the middle of the sprint, rather than always picking up “the next ticket,” they instead ask themselves, “What is the best thing I can do now to help us towards our goal?.”

Okay, that’s great, but how does it relate to lead time again?
When a team focuses on maintaining low lead time, it follows that developers will be more inclined to assist with in-progress work before picking up any new work; this is effectively swarming! On my teams at FloQast, we have developed a very simple framework for our sprint priorities that emphasizes “moving right to left” on the sprint board, meaning we prioritize pushing tickets over the finish line that are closest to “done” already. Priorities look like this:

• Work with QE if needed to push through tickets to production.
  This could mean clarifying requirements and/or testing scenarios for the ticket
• Code Review
• Checking in on teammates to see if they could use any help on “In Progress” tickets
  This could be helping them debug something, pair programming, or find an opportunity for parallel development on this ticket we missed during grooming.
• Start work on new ticket from TODO

As you can see, picking up a new ticket is last on this list. The framework encourages team goals over individual output, through swarming.

Closing Thoughts

In case you haven’t noticed, a lot of these concepts – low lead time, small batch sizes, continuous delivery, predictability, swarming, etc – are wonderfully interrelated, and each encourages the other; I believe that to focus on one of them is to effectively focus on all of them. At FloQast, we recognize and embrace each individually but are primarily driven by lead time as a metric for the health of our engineering department.

Good luck to all software teams out there, and may your lead time be ever low!

Dylan Caldwell

Dylan is an Engineering Manager at FloQast who aims to build performant and reliable teams that deliver valuable product. Outside of work he enjoys playing basketball and fantasy football.