Back with a quick article today. I’m here to discuss the cycle time definition from a software delivery standpoint. Not to be confused with the lean approach from automotive industry. However, I will talk about it from a software delivery standpoint. For a really in depth guide and how to roll this out organizationally potentially, check out DORA metrics which can go hand in hand with a potential agile solution for your enterprise. It’s important to not get lost into frameworks and process. Make sure the customer feedback loops are short, high value is being driven and internal team members feel satisfied and happy with the work as well.
What is cycle time?
Cycle time, in the context of software delivery, refers to the amount of time it takes for a piece of work to move through the team’s development process, from the moment work begins until it is completed. In other words, it measures the time taken from when the development team starts working on a feature, bug fix, or another unit of work, until it is ready for delivery or is delivered.
This includes all stages of the development process: coding, testing, and deployment. Cycle time is a critical measure of a team’s efficiency.
By monitoring and seeking to reduce cycle time, teams can identify bottlenecks or inefficiencies in their process, helping them deliver software more quickly and predictably. This is a vital part of applying lean principles to software development and is also used in Agile methodologies and DevOps.
For example, if your team’s average cycle time is two weeks, you can generally expect a new task to be completed two weeks after work starts on it. If the cycle time suddenly increases, this could be a sign of problems in your process, such as a bottleneck in testing or a problematic piece of work. By addressing these issues, you can reduce your cycle time and deliver work more efficiently.
Make sure you check out my article on reducing cycle time for a more in depth guide.
What is the cycle time formula?
Cycle time is a pretty straightforward metric to calculate. Here is the basic formula:
Cycle Time = Finish Time – Start Time
It’s important to note that these times should represent when work actually begins and ends on a particular task, feature, or project, not when it was initially requested or when it’s finally delivered to the end user.
For example, if a feature was started on June 1 and was finished on June 8, the cycle time would be 7 days.
However, in a real-world scenario, where you might have a large number of tasks or features to track, it’s more useful to look at average cycle time over a certain period, like per sprint or per month. You don’t need too many tickets to have a rough idea of cycle time. You can start getting a decent idea around 20ish or so.
Why is it important?
Reducing cycle time can have numerous benefits. It can improve customer satisfaction, as features and fixes are delivered more quickly. It can also increase your agility, as a shorter cycle time means you can respond to changes more quickly. Lastly, it can help improve predictability and planning, as with a consistent cycle time, you have a good idea of how long any piece of work will take to deliver.
I cannot stress enough that customer feedback loops and delivering value is one of the more important aspects of this. Don’t over stress the cycle time. Some teams will naturally be higher than others and some organizations will also be as well due to the nature of the business.
How do I begin?
The easiest way is to start manually. Go into jira or your favourite project management tool, then start looking at tickets. When did this get into development? That is your start date. When did this finish? That is your end date. Now go and subtract the two and you’ll get your first cycle time data plot. For example, on June 7th I started my ticket. On June 9th I finished the ticket. June 9th – June 7th = 2 days. Therefore, my cycle time on this task is 2! Keep doing this until you have a good scatterplot and some outliers.
When it becomes really painful you can look into tools that help you measure your cycle time. Make sure you understand your data by yourself first before spending a lot of money on tools that you may or may not use.
Closing
Cycle time is an easy to calculate metric that often gets lost in a lot of data. It’s one of the most important metrics from a software delivery standpoint but should not only be used alone. It should be combo’d with multiple other metrics in order to get a read on organizational health and areas of improvement / bottlenecks. If you’d like to get a measure on cycle time, just reach out to me. I’ve done manual pulls, semi automatic and fully automated solutions depending on the organization with some agile consulting.