Cycle Time

Cycle Time is a time measurement. It counts how long a single task takes, measured from the moment someone actually starts working on it to the moment the result is finished. The term originates from factory organization and is nowadays used primarily in software development. There, the task is usually a change to program code, and finished means: the change is running for the user. It’s important to distinguish this from the waiting time beforehand. If an order sits untouched in a list for three weeks and is then completed in a single day, the Cycle Time is one day, not 22.

What a short Cycle Time reveals about a team

Companies measure Cycle Time because it is one of the few honest numbers about work speed. It’s hard to sugarcoat. Either a change reaches the user after two days or after six weeks. Other metrics like the number of lines of code written say little, by contrast, because a lot of code is not the same as good code.

A short Cycle Time has a second, less obvious advantage. Those who deliver quickly deliver in small steps. Small steps are easier to check, and if something breaks, the cause is found quickly. Teams with long cycles, on the other hand, accumulate many changes and release them all at once. If something then goes wrong, someone has to search for the bug in a huge pile of changes.

For investors and executives, Cycle Time is also a signal of learning ability. A company that can test an idea in a week tries out far more ideas per year than one that needs a quarter for that. This is exactly why the metric regularly appears in reports on the productivity of technology companies.

How the clock is started and stopped

It is measured using timestamps from the tools teams already use anyway. A task board like Jira notes when a task switches from “open” to “in progress”. That is the start. The end is usually the moment of release, referred to in industry jargon as deployment. The difference between the two timestamps is the Cycle Time for that one task.

Things only get interesting with many tasks. Teams rarely look at the average, because individual outliers distort it heavily. More common is the median, i.e. the middle value of all measurements, or the 85th percentile. The latter answers the question: how long does it take at most in 85 out of 100 cases? This number is well suited for commitments to customers.

A common mistake is confusing it with Lead Time. Lead Time already begins at the order or the customer’s request and includes all waiting periods. A restaurant illustrates the difference well: Cycle Time is the time at the stove, Lead Time is the time from the order onward. If the two values are far apart, the problem doesn’t lie in the work itself but in full queues beforehand.

Cycle Time in products, statistics, and AI debates

Anyone dealing with software in a company encounters this metric on dashboards. Tools like GitHub, GitLab, Linear, or Jira display it automatically, often alongside metrics such as deployment frequency. It was made well known by the annual DORA study, which treats Cycle Time as one of four core metrics for good software teams. Top teams there fall in the range of under a day, weaker ones at several weeks.

In news about artificial intelligence, Cycle Time has now become a point of contention. Providers of coding assistants promise that their tools significantly reduce cycle times. Critics counter that faster-written code only shortens the first stage. Review, testing, and approvals remain the same length, and if the AI produces more faulty code, the total time can even increase.

Outside of IT, the original meaning lives on. In car manufacturing, cycle time describes how many seconds a vehicle spends at one station on the assembly line. In logistics, it refers to the time from order receipt to the packaged parcel. The basic idea remains the same everywhere: making the pure processing duration visible and separating it from waiting.