What is cycle time?

For most software developers, there is a constant push to deliver products faster. One popular way to understand how fast developers perform is by looking at cycle time, which measures how fast a team goes from starting work on a new feature to getting it out to users. But there’s a big question: Is keeping an eye on cycle time as helpful as people say?

Cycle time simply tracks how long it takes to get a piece of work from the start line to the finish line – from the moment a team begins working on a new update to the moment it’s in the hands of the users. It’s like timing a runner to see how fast they can complete a race. The idea is to see how quickly and efficiently a team can turn ideas into updates that people can use. Yet, as we take a closer look, it’s worth asking if focusing so much on cycle time is the right way to speed up and improve how we make software.

In this article, we’ll explore cycle time, why measuring cycles can be informative, and how it relates to measuring developer productivity.

Cycle time definition

Cycle time is how long it takes a software development team to ship or fix a new software feature through the entire software development lifecycle (SDLC). Specifically, it measures the duration from picking up a feature sourced from customer requirements to delivering it into production—and all the steps in between (design, development, testing, and deployment).

Cycle time has become a popular, simplistic measure of team productivity. It is not limited to software engineering. Other fields, such as manufacturing, also use this term to measure the time taken to create a deliverable, like producing a product or fulfilling an order.

In software, there are multiple ways to break down the components of cycle time. One approach divides it into the following categories:

Lead time

The time from customer request to pick-up of the feature (i.e., its inclusion in a product roadmap or an agile sprint)

Development time

How long it takes from pickup to the start of deployment (encompasses design, development, and testing)

Pickup time

The time from feature check-in to the start of code review

Review time

The duration of a code review

Deploy time

How long it takes to promote the new code to production so it’s available to customers

Why measure cycle time?

With modern Continuous Integration/Continuous Deployment (CI/CD) pipelines, many teams deploy application changes multiple times a week. Many deploy multiple changes a day.

A long cycle time (weeks or months) can signal that something is amiss with a team’s software development processes. Delays between conception and deployment slow down an application’s velocity, extending the time it takes to deliver feature enhancements to end users.

Long cycle times can also demoralize development teams. For example, if it takes three days of intense labor to promote a change to production, developers can become frustrated to the point where they dread pushing changes. This creates a negative developer experience, which can lead to lost productivity and accelerate team attrition.

What delays cycle time?

So, what factors can lead to long cycle times?

• Overload. If the team has too much on its plate, engineers might spend too much time context-switching between tasks to get a single set of changes out the door. This can also disrupt developers from entering a flow state, a period of dedicated concentration where developers typically exhibit peak performance.
  
  A lack of developers can lead to long lead times between client requests and pickup.
• Long code review times. Code reviews are indispensable to ensuring software quality. But long review times for pull requests will kill deployment velocity. A delay here might indicate that pull requests are too large - i.e., they contain too many files or too many commits - or contain unclear descriptions.
• Tooling issues. CI/CD deployment pipeline issues - e.g., a pipeline that’s brittle and hard to debug - are a significant culprit in inflated cycle times. Flaky tests that fail intermittently due to environmental factors and slow build times can also draw out cycle times. A lack of proper tooling for performing code reviews, poor integration between internal developer tools, and clear or up-to-date documentation for tools and deployment processes can create further delays.
• Technical debt. Technical debt is the accumulation of additional work required in current projects due to corner-cutting and shortcuts of expediency a team took in the past. One typical example is not correctly decoupling your application’s data and business logic layers because it’s “too much work.” Such shortcuts create brittle and highly-coupled components that are hard to change.
  
  Research such as the paper “Technical Debt Cripples Software Developer Productivity” have argued that technical debt can waste 23% of development time. Technical debt also leads teams to create more technical debt, causing the problem to snowball month over month.

If a team is suffering from long cycle times, chances are the cause is a combination of two or more of these factors.

How to address overly-long cycle times

Developer productivity cannot be solely measured by cycle time. In fact, it’s not the most reliable measure either. However, if your cycle times are increasing and causing obstacles to your overall ability to deliver software, then there is a high probability that you have significant issues with your overall software delivery process.

Here are some steps to take if you begin to notice lengthening cycle times:

Understand the issues

Begin by comprehensively understanding the causes of delays. This involves gathering both quantitative and qualitative data. For quantitative insights, capture critical metrics related to software delivery performance. For qualitative insights, engage directly with your developers to identify where they perceive bottlenecks and inefficiencies in the development process.

Analyze feedback

Once you’ve collected feedback and data, analyze it to pinpoint the issues that, if addressed, would most significantly reduce cycle times. Focus on the areas where improvements can have the most substantial impact.

Break work into smaller units

Consider adopting an agile development process. Break down larger features into smaller, manageable work items that your team can address within shorter cycles, such as two-week sprints. This approach can help in isolating and addressing issues more rapidly.

Improve code review efficiency

Enhance the code review process by either upgrading your pull request review tools or better integrating code review duties into your project scheduling. Aiming for quicker code review pick-up times and completion can significantly reduce cycle times.

Facilitate focused work time

Encourage and enable developers to set aside meeting-free and “do not disturb” periods. This dedicated focus time can help developers maintain a state of flow, improving productivity and efficiency.

Resolve tooling issues

Identify and fix any tooling problems highlighted by your developers or metrics analysis. Improving the tools your team uses can remove unnecessary obstacles and streamline the development process.

Enhance testing suites

Improve your testing processes by integrating more effective tests, such as regression tests that address areas previously known for deployment or build failures. Also, consider removing or improving flaky tests that contribute to unpredictability in your build process.

Can cycle time measure developer productivity?

After addressing the significant issues in their software development processes, some teams continue to focus on cycle time as a key productivity metric. In our experience, however, this is a mistake. It is not appropriate to evaluate developers’ productivity and performance solely based on their cycle time.

Once you’ve dialed in cycle time, eking out small improvements measurable in hours doesn’t do much to deliver additional value. Creating arbitrarily smaller units of work may create a nice downward trend line on a quarterly report to senior management. But how much additional value is that delivering to your end-users?

Part of the problem is that cycle time is an incomplete metric. It measures only how long it took to deliver a certain set of functionality; it doesn’t track how much you delivered.

The software industry has tried to quantify units of software delivery for decades, trying everything from lines of code to velocity points. None of these can provide an accurate, objective measure of work completed because the labor required for any given output unit varies dramatically from task to task. 100 lines of code can represent an hour’s work, whereas five lines of code may have taken a full day of research and testing.

At a certain point, focusing on cycle time yields diminishing returns. Leaders may end up pushing teams to move faster without delivering more. Especially if you’re not able to quantify throughput or the amount of work delivered, decreasing cycle time beyond a reasonable timeframe may not be an accurate indicator of improvement in your software process.

Once you’ve dialed in your deployment times to weeks or days, we recommend focusing on other drivers of deployment velocity and developer productivity. These may include reducing technical debt, increasing collaboration, improving the local development experience, or providing your teams with clearer direction.