The purpose of this post is to go through why Lead and Cycle times matters to an agile team. These two metrics are probably the most important in my opinion and I will explain why. For a brief overview of all agile metrics that matter, you can read up on that here. But let’s get into why using Lead and Cycle time can enhance your team.
Lead Time
Lead time measures the time it takes for an idea to make it into production. It starts when you create an item in the backlog and concludes when the team releases that work.
Essentially, it answers how long you will need to wait you can realize value in your software product. So, you should be able to do a bit of planning using this metric. That’s why it is there.
Why it matters
Lead time gives you an accurate representation of the performance of a whole team that not only develops the software but contributes to its development. In other words, if you are wondering how your busines analysis team members are doing, as well as your product manager, this is the metric for you.
What it tells you
The ideal lead time is the lowest amount of time that you can achieve. At some point you will hit a time where you plateau and can’t get any lower. That is when you have reached peak flow. Now, to reach peak flow, you optimize everything, including how you elicit and document requirements.
Let’s say that your development cycle is a constant 20 days and that we assume that amount of time represents a fully optimized cycle time (we’ll cover that in a bit). But your overall lead time is at 60 days. That means that you have ideas out in your backlog dormant for 40 days before it is in active development. That may not sound like a big deal to you, but a lot can happen in 40 days in our current business environment. The time you expended in defining something for the backlog may very well become waste if initiatives and busines needs change to where you no longer need development on those items.
Moreover, a key to business agility is “Just-In-Time” requirements. This concept originates from lean manufacturing where reducing inventories and waste by using materials that arrive just in time for building a product. Optimizing your lead time encourages the “Just in Time, Just enough” mindset that is needed for agile organizations. If you focus on lowering your lead time, that means you also need to identify features or value areas closer to the moment you need it. Your backlog should never be a collection of non-prioritized, dormant wish list items. Doing so would ensure a huge lead time, and a disorganized collection of work, where time spent reviewing old ideas goes to waste.
Cycle Time
Cycle time is the amount of time it takes for a work item or user story to get through the development lifecycle. It begins when a user story moves to being active, or in progress. Cycle Time concludes upon closing the work item.
Cycle time presents a more limited scope in terms of the calculation. It is specific to development and not idea creation, discovery, or idea validation. Therefore, it tells you how efficiently your development team is working (which includes QA, and the process of releasing items to production).
Keep in mind that even though Cycle Time is a measurement of the development process, there are times where the work items may take longer than expected because of requirements problems, or business changes. So, you need to eliminate those possibilities first before attributing problems to the development cycle.
Why it matters
Cycle Time matters because it shows you the overall efficiency for a work item to get from in progress to done. If you use an online tool like Azure DevOps, you can also see where your outliers are in terms of that cycle time. So, if you typically have a 20-day cycle time, but some user stories took 40 days, that would be a good indicator of a possible problem. Looking further into the outliers will help you work out issues in your process as well as reduce your cycle time.
What it tells you
Just like the ideal lead time is a lower value, the ideal cycle time is a lower timeframe. There will be a certain point at which your cycle time plateaus. Expect that plateau. All that means is that your team is running at its optimized efficiency in terms of the development process. Once you achieve that plateau, continue to monitor your cycle time to ensure that you catch problems as they arise.
As you monitor and optimize your cycle time, you will be able to find performance issues with individual team members. Use those as a means of coaching and mentoring. Perhaps a user story is using a new technology that a developer hasn’t used before. Do a lunch and learn to review that technology. The key to using cycle time metrics effectively is to use it as a chance to improve your team, not as a whip to beat them down.
Why These Metrics Matter
One of the reasons why I like lead and cycle time metrics is that it is hard to skew the results and show people something that doesn’t really exist. The time it takes to create, vet, develop, test, and release a user story is just time. There is no complex Fibonacci sequence that loosely correlates to some derivative of time based on the associated effort. People can’t inflate or deflate the amount of time something goes through the process. There is no estimate, it is just your past performance. Lead and cycle time are more quantitative than other estimates and less speculative. Because of that, it is great for better planning, refining, and optimizing a team’s agility.
Final Thoughts
I hope that this post piques your interest in what your lead and cycle time for your team is currently. If you start digging into it, perhaps you will find some ways in which your process can be fine tuned to enhance your ability to adapt and change with business environments, needs, and requirements. Some of the work management tools out there should be able to calculate these metrics automatically. If not, start tracking dates on your post it notes, index cards, or whatever tool you use to document your user stories or work items. After some time of tracking that data, you should be able to baseline your team’s performance and then optimize from there.
