Cycle Time

Ask a team how long it takes to deliver a typical piece of work and the answers will vary from hours to months. Cycle time replaces guesswork with data. It measures the elapsed calendar time between the moment someone starts working on an item and the moment it is done, including any time it spends blocked or waiting along the way. Because it is measured item by item, it shows not only the average but also how unpredictable delivery is, which matters just as much to the people waiting for the work. A team whose items take between three and five days is easier to plan around than one whose items take anywhere from one day to two months, even if their averages are similar.

Cycle time comes from lean manufacturing, where it measured how long a unit took to pass through a production process. In software, Kanban teams made it a primary measure, and it now appears in most agile tools, in flow metrics and, as lead time for changes, in DORA research. For engineering managers, delivery leads and product teams, cycle time is one of the simplest and most useful measures of delivery speed.

Definition of Cycle Time

Cycle time is the duration between the start of active work on a work item and its completion, according to a team's agreed definitions of start and done, typically measured in calendar days and analyzed as a distribution rather than a single average.

It is closely related to lead time, explained in lead time vs cycle time, is linked to work in progress and throughput through Little's Law and is a core Kanban metric.

How Cycle Time Is Measured

The team agrees on a start point, such as when an item moves to In Progress, and an end point, such as when it is deployed or accepted. Using the same points every time keeps the measure consistent.

Each completed item's cycle time is the difference between those two timestamps. Most tools calculate this automatically from workflow history.

Results are usually shown on a scatterplot, with each item as a dot, and summarized with percentiles, such as the 85th percentile, rather than averages. A few very slow items can distort an average. Percentiles also make simple service level expectations possible, such as a commitment that most items of a given type will finish within a stated number of days.

What Affects Cycle Time

Work in progress is the biggest factor. When a team starts many items at once, each one waits longer for attention.

Item size matters. Large items take longer and vary more, so splitting work into smaller pieces usually reduces cycle time.

Waiting for reviews, approvals, environments or other teams adds time without adding value, and often makes up most of the total. Rework adds time too. Items that fail testing or are reopened after release cycle back through the workflow and lengthen the total, which is why quality problems often show up first as longer cycle times.

Importance of Cycle Time in Delivery Management

Cycle time is a direct measure of responsiveness. Short, stable cycle times mean the team can respond quickly to customer needs and changing priorities.

It supports forecasting. Knowing that 85% of items finish within a certain number of days lets teams give reliable delivery estimates without detailed task-level planning.

It also exposes problems. A rising cycle time or a widening spread of results is often the first sign of blockers, overloaded teams or growing technical debt. Because it is measured from data the team already produces, cycle time requires no extra reporting effort once the workflow is defined.

Cycle Time and Financial Management

Long cycle times delay the value of finished work, increasing the cost of delay for revenue-generating features.

Work that sits partly done ties up engineering investment without returning anything to the business.

Shorter, more predictable cycle times let finance and product leaders plan launches and revenue more accurately.

Tracking cycle time before and after investments, such as automation or tooling, shows whether those investments improved delivery.

Common Challenges

Teams often start the clock at different points, making comparisons between teams misleading. Comparing a team with its own history is usually more useful.

Cards that are not moved promptly on the board produce inaccurate timestamps. Keeping the board current is a habit worth building.

Pushing for lower cycle time without addressing causes can lead teams to split work artificially or skip quality steps. Mixing very different kinds of work, such as small bug fixes and large features, in one chart can also hide useful patterns. Separating them by type usually gives clearer insight.