Why cycle time may be the most important metric in software development

There are various standard metrics that software development teams use to measure the performance of their development process.

My experience has led me to believe that cycle time is one the most important of all. It can tell you a lot about the way you work. Shorter cycle times mean an optimized software development process and faster time to market. Longer or lengthening cycle times mean there’s waste or inefficiency in the process, and delays for customers.

First, some definitions.

Cycle time, a metric borrowed from lean thinking and manufacturing disciplines, is simply the time it takes to bring a task or process from start to finish.

Within the task or process itself, there can be several individual elements that have their own cycle time, as the following diagram shows.

For example, the cycle time for software development, which goes from the beginning of coding to the release of the software, is different (and shorter) than the cycle time for the end-to-end process, but longer than the cycle time for reviews and verifications.

You can measure the cycle time of your end-to-end development process or a subset of the process that’s important to you.

In Klipfolio’s case, we started by measuring the development cycle time (see above diagram).

This involves measuring the cycle time for each issue (story, bug, etc.) we work on from the time we start coding until the issue is resolved and the code change is released to production and being used by the customers.

The following screen capture shows cycle time for our team. (We used our own software to build a dashboard to measure various teams’ cycle time.)

Cycle time is not hard to measure if you have the tools and the discipline to do it. What is difficult is coming up with an automated way of doing the measuring, since a software development team usually works on a large number of issues and tasks. However, unless you automate the measurement process, it's really hard to have enough valid data to be useful.

Why cycle time is so important

I have learned that average cycle time for your development process has a lot to say about your software development practices and the tools you use - code review tools, automated tests, deployment scripts, etc.

In simple terms, average cycle time tells you how long on average it takes for your team to take issues from the start to the finish line.

In a typical software development team, a lot happens between the start and the finish line. The following chart is an example of the usual development process.

So, how does knowing the average time from coding to production help you?

The key is to start tracking as soon as you can, and establish a baseline.

Then, by measuring variations in that baseline, you will know how you are doing.

For example, let’s say you know your average cycle time for delivering each bug fix is about two days. If there’s a sudden spike and the cycle time for bug fixes jumps to eight days, you know something is not right.

The problem could be anywhere in the process.

To be able to pinpoint it, you need to collect the cycle time for the key steps in your process.

Once you find out where the problem is, you can investigate that specific task or process and look for a solution.

For example, you might find you have intermittent failures in the automated tests in your deployment pipeline that are causing a bottleneck in the process, and therefore increasing the overall development cycle time.

Software development teams use many standard metrics to measure the performance of their development process, including number of defects, work-in-progress limits, burn rate, story points and investment distribution. Learn how to define your organizations KPIs.

They are all useful, but none of them reveal a wide range of issues in the development process. Measuring cycle time does.

Here are some other questions you can answer about your process using cycle time if you collect the right data:

• Does your team break down the stories into small enough increments?
• Are code reviews picked up quickly, or is there a wait time?
• Is there a problem in your pipeline tooling and process?
• Are the new servers that you need in the production environment built as quickly as possible by the operation team, or is there a wait time?
• How long is your quality assurance cycle time, and is there a bottleneck in your process?

I am curious to know how you use cycle time in your team. Drop me a line and let’s chat.

Ali Pourshahid, PhD, is Director, Software Development, at Klipfolio. He can be reached at @ali_pourshahid