How to better estimate when a new feature is going to be released

Cycle Time helps you better estimate time spent working on future tasks. It also helps you understand what the most common bottlenecks in your Software Delivery Pipeline are.

“We have a ton of [good] product pressure… We work really hard, but are fundamentally slow to deliver… This resonated everywhere. It takes a very long time to ship something here.’ – Artem Fishman, CTO at SoundCloud before putting efforts to measure and improve the software product development flow

How is Cycle time defined?

Cycle Time is a metric borrowed from lean thinking and manufacturing disciplines. It’s most often defined as the amount of time between the moment that works begins until it’s delivered to the end customer.

Is our Cycle Time too long?

In Google’s 2019 DevOps research, which included 31,000+ participants, Cycle Time was one of the core measurements. Authors grouped companies based on Software Delivery performance, where Cycle Time is:

  • Elite: less than a day

  • High: between one day and one week

  • Medium: between a week and month

  • Low: between one and six months

Authors also revealed that High-Performance Organisations are 106 times faster going from first commit to deployment. Additionally, they found that a small proportion of companies have an average Cycle Time of less than an hour.

Authors also revealed that High-Performance Organisations are 106 times faster on average going from the first commit to deploy. Additionally, they found out that a small proportion of companies have an average Cycle Time of less than an hour.

Why does shorter cycle time matter?

Shorter cycle times brings the following benefits to the team’s output performance:

  1. A faster feedback loop with your users

  2. Beating competition to market

  3. Reducing risk in the deployment process by working in smaller batches

Furthermore, metrics help the team have more productive standups. It gives the ability to spot bottlenecks and resolve them on the spot.

Be careful, Cycle Time alone is not enough!

Since Cycle Time doesn’t just measure Work In Progress speed but also other segments of the pipeline, it can be easily improved by removing code reviews or extended testing. This is, of course, counterproductive.

A reduced Cycle Time shouldn’t have any negative impact on other aspects of the team’s output quality. As a consequence, Cycle Time is usually accompanied by these 3 additional metrics:

  • Deployment frequency

  • Time to restore service

  • Change failure rate

High Performance

Ideally, we want to transition to what is called a “one piece flow,” a process where all code inventory is actively being worked on. In the first three months, the team’s cycle time dropped from 12 days to 3 days.SoundCloud

Ideally, your developers should be checking multiple small releasable changes into the trunk at least once per day.Google

Athenian approach

In Athenian, Cycle Time is computed as a sum of the average time required in each step of the Software Delivery Pipeline that has been released.

It’s important to understand that each segment’s average time is first computed separately, including all Pull Requests already past this stage (even if not released).

With Athenian’s Software Delivery Performance dashboard, you can quickly spot which segment of the pipeline adds the most time to total cycle time. Generally speaking, this segment should then be tackled first.

Where can I learn more?

Siemens’ Health Services department has a case study digging into how they shifted from traditional agile metrics (eg. Story Point, Velocity) to more actionable metrics like Work In progress, Cycle Time, and Throughput. Some key points:

  • In the last week of boxed sprints, they usually saw a mad rush for Story Points

  • Work was started at a faster rate than it was closed

  • With the introduction of Cycle Time, real-time transparency finally came

  • Forecasting improved based on Cycle Time history and backlog size

Why isn't my Cycle Time the exact sum of all segments?

Sometimes customers start to add up the numbers and they notice that the Cycle Time is not the exact sum of all the underlying segments. This happens because we designed the product to be as effective as possible to give you actionable insights. When you look into the individual segments you have the data of everything that has been pre-processed up to that segment, e.g. all code that was already reviewed appears in the Review segment, even if it that code has not yet been merged. For the Cycle Time we use everything that was released, meaning the average of all historical data released, so code that has been reviewed but not released will not impact Cycle Time.

Why did we do this? Imagine that you have an issue in the Review segment. As we decided to show everything that has been reviewed you'll immediately start to see trends and you'll be able to course correct immediately, instead of waiting for those PRs to be released and only at a later stage have the data available to change something. This is the difference of having lagging or leading metrics, whenever possible we opt for leading and so should you.

Did this answer your question?