Cycle Time is an end-to-end measure of your software development productivity. It measures how long it takes for an idea to go from development to being in front of users in production.

Many notable engineering teams (like Google and Spotify) have achieved remarkable success by optimising Cycle Time.

Strengths

Hollistic EngProd Metric

Cycle Time measures what happens from a developer picking up some work, through to it going into production.

Many engineering leaders fall into the trap of measuring one indicator (say, deployment time) without understanding how the entire picture looks. Focus in only one local area can lead to optimisation where no bottleneck exists.

By looking at a global metric, you can optimise the entire Software Development Lifecycle.

A Metric for Engineers

As Cycle Time measures engineering process, rather than product outcomes, it is a measure that is actionable for engineering teams.

The engineering team can take complete ownership of improving it without external dependencies.

Product Managers will continue to prioritise work as makes sense for the business, but engineering will be able to deliver that work faster.

Optimises for Flow

As described in Why Shipping Software Smaller Helps Deliver Better Product, it is better to optimise for flow instead of just the volume of work delivered. Improving flow allows you to deliver better business outcomes reliably whilst preventing developer burnout.

Cycle Time encourages focus on a flow instead of using lower-impact flow based metrics.

Actionable

Having this hollistic picture allows you to drill into problem areas.

For example; after seeing typical Cycle Times, you may notice that work is slowing down during Code Review. Drilling further, you might see that it takes too long for first code reviews to be completed due to slow builds blocking the approval workflow.

By first looking at the global picture and then drilling down into local areas, you are able to improve the entire Software Development Lifecycle, instead of just one area.

Limitations

No Quality Measure

Cycle Time will measure speed, but it won't measure quality. It should typically be paired with strong engineering practice (in managing the balance of risk and reward, to maintain reliability) alongside more quantative measures of reliability.

For example; whilst Cycle Time is a key metric for engineering performance, it might also be worthwhile looking at Median Full Resolution Time for bugs to ensure that customer bugs are resolved in a timely fashion.

Risks

As Cycle Time is a lagging indicator, it can be hard to gain visibility into risks early when using it. Ideally you want to address risks before they turn into metrics.

Using alerts, teams can track when issues start to appear before they turn into issue. For example; Slack alerts warning when a Pull Request is stuck in review or back-and-forth discussion can allow issues to be resolved promptly.

Cycle Time is mainly a metric used to identify and optimise existing bottlenecks, on it's own it might not be enough of an "early warning system".

Conclusion

Cycle Time is our favourite EngProd metric, it provides the insights you need to drive performance anywhere in your Software Development Lifecycle.

That said, it's critical to beware of any risks that appear and remember to use it in conjuction with quality metrics.

Remember that to effectively optimise Cycle Time, you need to address the process problems. Look at the data for a team or organisation and optimise it there. Don't try to use it as a metric to micromanage staff, else you'll just get employee burnout.