What Cycle Time Tells Us About Delivery
Cycle Time measures the journey of a feature from idea to running in production. Agile teams work to keep this interval short by shipping small features and trimming delays from their process. Yet while the broad idea is widely understood, the precise definition of when the clock starts — and when it stops — is surprisingly inconsistent.
The emphasis on fast feedback is a core reason agile methodologies favor iterative development over a Waterfall Process. Decomposing work by functionality rather than activity creates a feedback loop: place a small feature in front of users, learn from their reaction, and adjust the product and the process accordingly. Speed in that loop compounds; the quicker feedback arrives, the more useful it is. That motivation drives the push to reduce cycle time.
Where the Clock Starts and Stops
Deciding the stopping point is the easier of the two. The natural end is when the feature reaches production and starts delivering value to users, but complications arise quickly. If a team uses a Canary Release, is the measure satisfied when the first cohort sees the feature, or only after wide release? If an app store approval gate sits in the path, do we include that unpredictable delay even though it's largely outside the team's control?
Start time invites even more divergence. A common and practical marker is the developer's first commit to the feature branch, but that omits any effort spent in upfront analysis. Some teams extend the window back to the moment a customer first expresses an idea — reasonable for a high-priority item, but misleading for something that sits in a triage queue for weeks before it earns development attention. For such features, starting the clock when the work enters the card wall might be more representative.
Teams sometimes use the phrase lead time in place of cycle time, or alongside it, usually to denote a different starting point. There's no standard convention for how the two are split, so treating lead time as a synonym is safer. When someone uses both, it's worth asking how they draw the line; when it's useful to separate multiple intervals in one context, explicit adjectives like "first-commit cycle time" versus "idea cycle time" are clearer than an idiosyncratic lead/cycle distinction.
A Slippery Metric With Real Value
The lack of a single canonical definition means cycle time is inherently ambiguous. Comparing numbers across teams is risky unless both parties can confirm identical start and stop rules. Differences in process — triage workflows, release gates, definition of "done" — can skew what looks like a straightforward benchmark.
That ambiguity doesn't undermine the concept's value. Building a value stream map from idea to production, tracking the time spent on each step and the waiting between steps, often exposes opportunities for improvement. Two interventions that repeatedly help are shrinking feature size and, counter-intuitively, increasing Slack. The effort to understand and shorten the flow is worthwhile because faster delivery means benefits reach users sooner and feedback arrives quickly enough to keep improving the way the team works.
