Cycle time is a crucial metric in project management and agile methodologies that measures the amount of time it takes to complete a task, once work has started on the task. It is an essential indicator of efficiency and productivity, helping teams understand how quickly they can deliver value to customers. In this article, we will delve into the confusion between cycle time and lead time, explore how to calculate cycle time in Jira, and discuss how to optimise cycle time.
Cycle Time vs. Lead Time
Lead time and cycle time are often confused but represent different aspects of the delivery process.
Cycle Time: This measures the time taken to complete a specific task or process from the moment work begins until it is finished. It focuses solely on time to complete the work once it has started. It will include all work and waiting periods encountered during this time.
Lead Time: This encompasses the entire duration from when a request is made or a task is created until it is delivered to the customer. Lead time includes all waiting periods, such as time spent in backlog, as well as the actual work time. As such, cycle time will always be a subset of lead time.
Fig 1. Cycle Time Vs. Lead Time
How to Calculate Cycle Time in Jira
Jira, a popular project management tool, provides various methods to measure and track cycle time. Here’s how you can do it:
1. Jira Reports:
Jira’s Control Chart helps visualise cycle time for your issues. Navigate to Reports in your project sidebar, select Control Chart, and set the time range. The chart displays the cycle times for issues, allowing you to spot trends and variations.
2. Custom Fields and Filters:
Create custom fields to log start and end dates for each task. You can then use JQL (Jira Query Language) to filter and calculate the time between these dates.
3. Add-ons and Plugins:
Jira apps, such as Delivery Flow, offer enhanced tracking and reporting capabilities for cycle time as well as other flow metrics. Delivery Flow provides detailed insights and automated calculations for cycle time at an issue level and average cycle time at a system level.
What to Measure
Traditional project management focuses on individual tasks, whereas cycle time is a flow metric for system-level analysis. To measure average cycle time, track the total time to complete a set of tasks and calculate the average. This set of tasks could be all the work items for one team or all the work for your entire group. You get to determine the bounds of the system being measured.
Ideally, the system we are measuring is relatively stable. For example, if we define the system to be the work stream of our payments development group but we keep changing the capacity of that group, then we will receive unstable results that are a reflection of these changes. It will be difficult to trend data over time and understand the signals in the data.
When measuring cycle time and lead time, we use 24 hour days and 7 day weeks. For instance, an item may arrive on a Monday and finish on Wednesday the following week, resulting in a 10 day lead time. Initially, engineers often dislike this approach. This measurement standard aligns with flow metrics for a simple reason. From your customers perspective, it took 10 days from request to delivery. Weekends and time-off are irrelevant in this context. For engineers who are sensitive to this, it’s worth remembering that average cycle time is a measure of the delivery system, not individual performance.
Finally, only completed items should be included in your calculations. Measure items completed within a period (daily, weekly, or monthly) to trend average cycle time over time, helping you to understand if average cycle time is increasing or decreasing. Measuring average cycle time provides a comprehensive view of overall process efficiency, highlighting systemic bottlenecks and trends, rather than isolated anomalies. This allows for the identification of effective process improvements.
Where to Start
In Jira, workflows are the steps work must pass through before it’s considered done. In Flow terminology, this is known as a value stream. Potential value enters the stream and flows from start to finish, where it is realised as customer value.
Mapping and measuring the full value stream is essential to understand your delivery system’s behaviour. Measuring only part of the value stream can result in local optimisations with minimal impact on overall results. Ideally, for cycle time, start the clock when work enters development and stop it when it is deployed to production.
However, I have contradictory advise for beginners – start small. Focus on the portion of the value stream where you have the most control and influence. In one organisation, I started with the first three steps: Development, Ready for Review, and Code Review. This gave the development team maximum opportunity to setup, measure and learn successfully. The improvements we made were local optimisations only but this built confidence and enabled us to spread the Gospel with the owners of the other steps in the value stream. So you can start small but always be aware that the goal is to understand how value flows through the entire delivery system, not just your part of it.
How to Improve Cycle Time
Improving cycle time depends on the specific context of each organization. To identify bottlenecks, measure cycle time for each step in the workflow, in addition to the overall workflow. This reveals where time is being spent in your delivery system. When done for the first time, it often uncovers surprising insights and hidden inefficiencies, providing a clear view of your workflow that helps drive further investigation and improvement.
Below is an example of workflow cycle time measurements for an organisation using Delivery Flow for the first time. The cycle time for each step is shown as a percentage of the total time. I will let you draw your own conclusions on the data but I think it is fair to say that this organisation was surprised to see where they were spending most of their time.
Fig 2. Process step timings from Delivery Flow
I should also mention that to fully understand cycle time results, you may need visibility on other flow metrics like Work In Progress (WIP). For example, if WIP doubles from one month to the next, average cycle time will also increase. According to Queueing Theory and Little’s Law, more work means longer completion times. We don’t need to delve into the science, it is intuitive. More load on the same capacity will lead to longer average completion rates.
Conclusion
Cycle time is a vital metric for understanding and improving delivery efficiency. By differentiating it from lead time, accurately measuring it in tools like Jira and Delivery Flow, and implementing strategies to optimise it, delivery organisations can reap significant benefits, including enhanced productivity, customer satisfaction, and cost efficiency. Consistently monitoring and optimising cycle time is essential for maintaining a high-performing delivery organisation.