Why You Should Measure Cycle Time ➰

A primer on the most popular engineering metric.

Last week we explored software delivery metrics and how they predict overall engineering efficiency.

This week I follow up, with a broader scope, to discuss my favorite metric of all: Cycle Time.

πŸ“ˆ The Rise of Engineering Analytics

Over the last couple of years, several analytics tools rose to support a data-driven approach to Software Engineering.

You may (or may not) know a few of them: LinearB, Code Climate, Waydev, Flow.

They connect to your code hosting (e.g. Github) and automatically create measures based on commits, PRs, and releases.

Among these measures, I would argue that Cycle Time is the most significant one. To the point that if you had to focus on just one KPI for your dev process, it should probably be it.

Let's see what it's all about.

πŸ€ The Four Stages, and Lead Time

Depending on who you ask, dev life cycle has four to eight steps, and even Google seems to be a bit confused about it.

For the sake of this topic, let's keep it simple and consider four of them:

  1. πŸ“‹ Design β€” requirements and analysis are performed. Work is split into batches and properly planned.

  2. πŸ”¨ Coding β€” code is written by devs, together with tests and further docs.

  3. πŸ” Review β€” code is reviewed, in multiple ways: CI pipeline performs tests, peers perform code review, QA possibly steps in.

  4. 🚚 Deploy β€” code is merged on the production trunk and released.

The time that goes from Design to Deploy is called Lead Time.

Agile's main teaching, with respect to Waterfall, is to keep Lead Time short.

Lead Time, however, is an all-in-one metric β€” it includes everything. It's not easily actionable, because it's the sum of very different steps.

➰ Cycle Time

As seen last week, a great strategy to keep Lead Time short is to focus on the Review and Deploy steps.

These are predictable activities that can be made efficient via Continuous Delivery practices. Run automated tests. Deploy in 10 minutes. Recover fast.

Lead Time covers all the four steps, and delivery metrics the last two. Cycle Time hits the sweet spot by covering Coding, Review and Deploy.

Cycle Time is defined as the time that goes from the first commit to the release in production.

The intuition behind it is that by working in small batches and making delivery efficient, Coding time should become predictable too. This way, Cycle Time becomes a reliable measure that can be analyzed and optimized over time.

But why is Cycle Time such a good metric?

βš–οΈ The Virtues of Cycle Time

Cycle Time possesses all the hallmarks of great KPIs:

  • It's objective: it doesn't need context to be interpreted, you know exactly what it means.

  • It's easy to understand: it can be easily discussed and explained to management, as it works like the engineering equivalent of sales cycle and product funnel metrics.

  • It stays relevant as you scale: it doesn't depend on the size of the team.

  • It's actionable: it shouldn't fluctuate much. Significant increases usually point to specific problems that can be identified and resolved.

πŸ” How to Measure Cycle Time

If you want to track Cycle Time in your team, there are several tools that allow you to do so, also with a breakdown of the various steps. This is a partial list:

They integrate with your code hosting to monitor commits, PRs and releases, and compute numbers automatically.

In alternative, you can track it on various project management tools like Jira, or Clubhouse (not that Clubhouse!) β€” but in this case you only get the aggregate number, without the chance of drilling down into the single steps.

πŸ“š Resources

A lot of resources this week! It's a hot topic and there is no lack of quality content about it, as more and more people get interested in starting a metrics program in their team.

Here are a couple of great primers, provided by tools from the list above:

For a wider perspective, you can also check these:

And that's it for this week! Do you have any experience working with Cycle Time and other engineering metrics? Let me know in the comments or via email!


Hey, I am Luca πŸ‘‹ thank you for reading this far!

Every week I read tens of articles and draw from my own experience to create a 10-minutes advice about some engineering leadership topic.

Subscribe below to receive a new essay every Friday and put your own growth on autopilot!