CodeKuduCodeKudu

Cycle time

Cycle time is the elapsed time work spends moving through your delivery pipeline—from start to done—though exact start and end points depend on your tool and process.

Definition

In software delivery, cycle time usually describes how long a unit of work (often a task, user story, or pull request) takes from the moment it enters active development until it is considered complete—typically merged, released, or delivered to users, depending on your definition.

The phrase is borrowed from manufacturing and Lean; in engineering organizations it is not standardized. One team may measure from “In Progress” to “Done” in Jira; another from first commit to production deploy. Comparisons across teams only make sense when those boundaries match.

How teams typically measure it

  • Issue trackers: time between workflow states (for example, when a card moves into development until it reaches “Done” or “Released”).
  • Version control: time from first commit on a branch to merge, or from PR open to merge—useful for review bottlenecks but not the same as end-to-end product cycle time.
  • Some analytics products blend signals (PRs, deploys, issues); always read how the vendor defines start and stop events.

Common pitfalls

  • Treating cycle time as a personal productivity score. It is a system property: priorities, batch size, review load, and dependencies dominate.
  • Optimizing cycle time by skipping testing or review—short-term “gains” that increase change failure rate and rework.
  • Confusing cycle time with lead time for changes (DORA): lead time is anchored on the commit (or production-ready change) to production; cycle time in many tools starts earlier (e.g. when work is “started” in a board).

Related terms

Browse other entries in the glossary.