Cycle Time: Measuring Your 'Time to Value'

The mental model

Cycle Time is the total duration it takes for a new feature to travel from its initial idea all the way to running in production and delivering value to users. Think of it as the "time-to-value" for a single piece of work. In agile development, the primary goal is to make this time as short as possible to accelerate learning and feedback.

How it works

Measuring cycle time seems simple, but its definition is slippery. The main challenge lies in defining consistent start and stop points. The start time could be when a customer first has an idea, when the team adds the feature to their work board, or when a developer makes the first code commit. The stop time is also variable: is it when a feature is live for a small group in a canary release, or only when it's fully rolled out to all users? Because of this ambiguity, it's better to use descriptive phrases like "first-commit cycle time" or "idea-to-production cycle time" rather than arguing over the difference between "cycle time" and "lead time," which are often used synonymously.

When to use it

Use cycle time as a diagnostic tool to improve your own team's delivery process. The most effective way to do this is by creating a value stream map, which visualizes every step from idea to production. This map highlights not just the time spent on active work (like coding or testing) but also, crucially, the waiting time between steps. Understanding this flow helps identify bottlenecks and opportunities for improvement, such as reducing feature size or increasing slack in the system.

When not to use it

Avoid using cycle time to compare the performance of different teams. Unless two teams have an identical, explicitly agreed-upon definition for their start and stop times, the comparison is meaningless. Using it as a competitive metric can lead to teams gaming the numbers—for example, by starting the clock later in the process—rather than making genuine improvements to their workflow. It is a tool for internal improvement, not external ranking.

One canonical example

A team notices their features take over a month to ship. They map their value stream and find two major delays: features are too large, taking weeks to build, and completed work waits an average of five days in a queue for manual testing. To shorten their cycle time, they focus on two changes. First, they break down large features into smaller, independently shippable stories. Second, they adopt a whole-team approach to quality, with developers helping test work to clear the queue. Their average cycle time drops from 30 days to just 8 days.