What is cycle time?
Cycle time is the elapsed time from when active work begins on a task to when that task is completed. On a kanban board, it is typically measured from the moment a card enters the In Progress column to when it reaches the Done column. Cycle time captures the actual duration of work, including development, review, testing, and any wait time between those active stages.
Cycle time differs from lead time, which includes the period before work starts - time spent in the backlog or waiting to be prioritized. A task might have a cycle time of two days but a lead time of three weeks if it sat in the backlog for 19 days before anyone picked it up. Cycle time tells you how efficient the team is once work begins; lead time tells you how responsive the team is from the customer's perspective.
Why cycle time matters
Cycle time is the most actionable flow metric for engineering teams because it directly reflects the team's capacity to deliver. A team with a consistent average cycle time can make reliable predictions about when work will be finished. If the average cycle time for a bug fix is 1.5 days, stakeholders know what to expect when they report a bug. If it is four days, something in the process - large batch sizes, slow reviews, unclear requirements - needs attention.
Tracking cycle time over weeks reveals trends. A rising average cycle time often means the team is taking on work items that are too large, accumulating too much work in progress, or struggling with review bottlenecks. A declining average means process improvements are working. Unlike story points or effort estimates, cycle time is an objective measurement of what actually happened, not a subjective prediction of what might.
How to reduce cycle time
The most effective lever is reducing work in progress. Little's Law states that cycle time equals WIP divided by throughput. Lowering WIP while keeping throughput constant directly reduces cycle time. Beyond WIP limits, teams can reduce cycle time by breaking work into smaller cards (a card that takes one day instead of five reduces variability), by making reviews faster (setting a team norm for review turnaround), and by removing handoff delays between stages.
Watch for cards with cycle times that are two to three times the average. These outliers often reveal systemic issues: unclear requirements that required rework, dependencies on external teams, or scope creep that turned a small fix into a large feature. Investigating outliers is often more valuable than optimizing the average.
How Flux supports cycle time tracking
Flux's event-sourced activity log records every column transition with a timestamp. When a card moves from In Progress to Review, and from Review to Done, those timestamps are captured automatically. This data gives teams the raw inputs to calculate cycle time for individual cards and to track averages over time. The Done column marker provides a clear boundary for cycle time measurement, and the real-time sync ensures timestamps reflect exactly when transitions happened, not when someone remembered to update a status field.
Related terms
See also: Lead Time, WIP Limit, Throughput.