Cycle Time: Definition, Formula, and Why It Matters for Engineering Teams

What Is Cycle Time?

Cycle time is the total elapsed time it takes to complete a single unit of work, from the moment active work begins until the work is ready for delivery.

In software development, cycle time specifically measures how long it takes to move a change from "actively being worked on" to "deployed to production." It's a measure of development velocity and process efficiency.

The key distinction: cycle time only counts active work time. It doesn't include time spent waiting in a queue, reviewing, or blocked on dependencies. That waiting time is part of lead time - a different metric entirely.

Cycle Time Formula

The most common way to calculate cycle time:

Cycle Time = End Date - Start Date

More specifically in software development:

Cycle Time = (Time PR Merged) - (Time Work Started)

Or in an Agile context:

Cycle Time = (Time Task Moved to Done) - (Time Task Started)

Some teams prefer:

Cycle Time = Total Time to Complete / Number of Units Completed

This gives you an average cycle time, which is more useful for tracking trends over time.

For example: If your team completed 40 tasks in a month (160 hours of work days), your average cycle time would be 4 hours per task. If a single feature takes three days from start to deployment, the cycle time for that feature is three days.

Cycle Time vs Lead Time: A Critical Distinction

People ask this question constantly because the terms sound similar but measure very different things.

Cycle Time:

• Starts when work actively begins
• Ends when work is ready for delivery
• Measures only active work time
• Excludes waiting, queuing, and blocked time

Lead Time:

• Starts when work is requested or initiated
• Ends when work is delivered to the customer
• Measures total elapsed time from request to delivery
• Includes waiting, reviewing, deployment, and everything else

Think of it this way: a task gets requested on Monday. It sits in the backlog for a week. On the second Monday, an engineer starts working. They finish on Wednesday. The feature ships on Thursday.

• Cycle Time: Wednesday - Second Monday = 2 days (only the days actively being worked on)
• Lead Time: Thursday - Monday = 10 days (the entire span from request to deployment)

This is why cycle time is often much shorter than lead time. A task might have a cycle time of two days but a lead time of two weeks because it was waiting in the backlog for ten days.

For engineering leaders, this distinction matters enormously. A long lead time might indicate that your process is slow - but it might also just mean your backlog is large. A long cycle time indicates that the work itself is taking a long time, which usually means either the task is genuinely complex or your team is blocked by dependencies.