What is Cycle Time?


Cycle Time measures how long it takes work to exit a system from start to finish. "Work" is a ticket in your project tracking software of choice, think: Jira, GitHub projects, Trello, etc. The clock starts when an engineer begins their coding effort for a ticket. Creating a new branch is the action that usually marks the beginning of the effort. The clock stops when you deploy that work to production.

Notice the word "deployed" here. "Deployed" is different than "released". Deployed means the code is on the server, but it is not necessarily seen by 100% of its intended audience. The code may be behind a feature flag. A feature may impact none of it's intended audience at deployment time. The work is deployed, but it may only be partially released. Deployed work is still valuable for your product. It may only be visible to QA engineers or a subset of your users, but it is still adding value. This makes an deployment time a worthwhile finish line for Cycle Time.

This post will explain what Cycle time is and how it affects software delivery. Calculating Cycle Time is a contentious topic which we've addressed in another post. Let's talk about the real-world effort that Cycle Time measures.

Cycle Time and Software Delivery#

Cycle Time measures the average time work is in progress. "Work in Progress" (WiP) covers several phases depending on your software development process. Common phases of WiP include:

  • Development by an engineer
  • Peer review by other engineers on the team
  • Verification by QA
  • Acceptance by a Product Manager
  • Release management
  • Deployment to production

The great thing about Cycle Time is that it includes all the potential bottlenecks in a delivery pipeline. There are choke points where WiP can queue and wait. Your goal is to optimize the bottlenecks. Is work waiting for deployment? Make deployments as easy as pushing a button (then automate the button-pushing :). Is your team handcrafting each release with cherry-picked commits? Move to trunk-based development. Scrutinize each bottleneck to decrease your WiP and increase your throughput.

Taking Control#

That last sentence is the crux of improving your Cycle Time: decrease your WiP and increase your throughput. As engineers we like to ship code. Let's create an example with another kind of ship. Imagine a canal waterway. Our goal is to minimize the amount of time a single boat spends in this waterway. Think of WiP as the total number of boats in the canal. Throughput is the number of boats that exit the canal for a given time. To illustrate the interplay between throughput and WiP imagine the following parameters:

  • High WiP = 6 boats
  • Low WiP = 3 boats
  • High Throughput = 2 boats/day
  • Low Throughput = 1 boat/day

A simple way to calculate Cycle Time is WiP/Throughput. The following diagram illustrates how WiP and throughput affect the average time a boat stays in the canal:

Throughput and WiP

This diagram illustrates the sweet spot of high throughput and low WiP. Try to apply this to your decisions while developing software. Ask yourself, "How does this decision impact throughput? How does it impact WiP?"

Cycle Time and Products#

Cycle time measures the barrier to delivering value to your users. The lower your Cycle Time the more quickly you can improve your product. Cycle Time emphasizes throughput. It's best balanced with other measurements that emphasize stability.

As your Cycle Time decreases each parcel of work generally becomes smaller. This makes your delivery pipeline more nimble. You'll be able to adapt and change course if you find the latest work you delivered didn't have the impact you expected.

Cycle Time is a comprehensive, versatile metric. It's a boon to any developer concerned with maximizing the impact of their effort. Tracking and improving Cycle Time will lead to a streamlined, automated software delivery pipeline. This is bound to make developers more happy as they spend their time actually improving the product. Toiling with painful releases and deployments is the path to developer burnout. Users are more happy as they see quick and regular improvements to the products they use.