Cycle Time
Cycle Time measures the amount of time it takes to complete a task once active work has begun. It reflects how quickly work moves through the delivery process after it is pulled from the backlog.
Calculation
Cycle Time is calculated by measuring the time between the start of active work and the point of completion:
cycle time = task completion time – task start time
Goals
Cycle Time helps teams evaluate the speed and consistency of their delivery process. It answers questions like:
- How long does it take to complete a task once it enters development?
- Are there consistent bottlenecks in our delivery flow?
- Are we improving our delivery speed over time?
Reducing cycle time enables tighter feedback loops and faster learning. For a data-driven breakdown of cycle time modeling, see minware’s report on Lead/Cycle Time and Workflow.
Variations
Cycle Time may also be referred to as Task Cycle Time, Ticket Cycle Time, or Development Cycle Time. At minware, this metric is broken down further into multiple analytical perspectives:
- Ticket Cycle Time (TCT): Time from when a ticket moves to an “in progress” state until it is completed. Reflects overall execution speed.
- Pull Request Cycle Time (PRCT): Time between PR creation and merge. Captures how long code spends in review and validation.
- Stage-Specific Cycle Time: Measures time spent in coding, review, testing, and deployment stages individually.
- Long Cycle Time Tickets (LCTT): Flags tickets that exceed a defined cycle time threshold (e.g. 4 weeks) to identify and address stalled work.
Cycle Time and Lead Time are often considered variations of each other, but each is unique. While Cycle Time tracks time from start to finish of active work, Lead Time includes the full timeline from task creation, including time spent waiting in the backlog. Lead Time provides broader visibility into planning and prioritization delays, while Cycle Time offers deeper focus on workflow execution.
Limitations
Cycle Time highlights how long tasks take to complete once started, but it doesn’t account for time spent waiting in the backlog or before prioritization. It also doesn’t indicate why a task took longer, whether due to technical complexity, delays in review, or cross-team dependencies.
To better understand where delays occur and how to address them, pair Cycle Time with:
| Complementary Metric | Why It’s Relevant |
|---|---|
| Lead Time for Changes | Provides visibility into delays before development begins, not just execution time. |
| Flow Efficiency | Reveals how much time in Cycle Time was spent actively progressing versus waiting. |
| Review Latency | Isolates how long tasks are delayed in peer review, often a major cause of long cycle times. |
Optimization
Improving Cycle Time involves removing delivery bottlenecks, breaking work into smaller increments, and increasing team focus on finishing started tasks.
-
Limit WIP. Too many in-progress tasks increase context switching and delay completion. Use WIP Limits to keep cycle time stable.
-
Swarm on stuck work. Teams should prioritize completing in-flight items before starting new ones. Swarming shortens lead time and exposes blockers early.
-
Break down large tasks. Oversized stories or tickets are harder to complete and often mask multiple units of work. Aim for atomic, testable slices of functionality.
-
Improve handoffs and automation. Long review or test handoffs extend cycle time. Apply Code Review Best Practices and build [CI/CD] automation to reduce handoff delays.
-
Track aging tickets. Surface tasks that have remained in progress for too long. Older items tend to accumulate risk, scope creep, or unclear ownership.
Reducing Cycle Time leads to faster iteration, clearer delivery rhythm, and more predictable execution, key ingredients for agile teams working at scale.
