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.
Why does shorter cycle time matter?
Shorter cycle times brings the following benefits to the team’s output performance:
- A faster feedback loop with your users
- Beating competition to market
- 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
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
In Athenian, Cycle Time is computed as a sum of the average time required in each step of the Software Delivery Pipeline.
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
