Cycle time
The average time from when work is started to when it is delivered — a flow metric for end-to-end delivery throughput.
// Formula
// About this metric
Cycle time measures the elapsed time from when work is actively started (status moves to "in progress") to when it is delivered (shipped to production or accepted by the customer). It is a flow metric from lean manufacturing adapted for software development, distinct from lead time (which starts from first commit) and from throughput (which counts items delivered).
Short cycle time is associated with several benefits: faster customer feedback, lower work-in-progress inventory, easier defect attribution (smaller changes are easier to reason about), and higher team morale. DORA research supports cycle time as a predictor of organisational performance, though the correlation is measured via lead time in the DORA framework.
Cycle time is highly dependent on how work is sliced. A team that breaks features into user stories of 1–3 days of work will have a dramatically shorter cycle time than a team working on multi-week feature branches, regardless of engineering velocity. This is why cross-team benchmarks are unreliable — a team with a 25-day cycle time may be delivering similar features to a team with a 3-day cycle time, but one slices work more finely.
Track cycle time distribution rather than just the average. A long tail of items stuck in progress for weeks is a bigger problem than a slightly elevated average. Items in the 90th percentile of cycle time are usually blocked on external dependencies, scope creep, or unclear acceptance criteria.
// Calculator
🧮 Calculator
// Benchmark
// When this is healthy
Healthy cycle time varies by item size — track distribution and trend, not absolute number. A team where most items finish in under 7 days is operating with healthy slice sizes. >30 days average suggests stories are too large, dependencies are blocking, or both.
// Why no numeric benchmark
Cycle time depends entirely on how teams slice work. A team that ships large stories every month and a team that ships small stories every day both have 'healthy' cycle times — but the numbers look completely different. Track YOUR trend.
// When to use this metric
Use cycle time to understand your team's delivery rhythm and to identify stories that are blocked or oversized. Review the cycle time distribution at sprint retrospectives: outliers — items that took 5× the team median — are the starting point for process improvement conversations.
Pair cycle time with lead time for changes: if cycle time is much longer than lead time, the bottleneck is in planning and refinement rather than in the engineering pipeline.
// Common pitfall
Cycle time depends entirely on how teams slice work — a team that ships large stories every month and a team that ships small stories every day both have "healthy" cycle times that look completely different in absolute numbers. Never compare cycle time across teams without accounting for story size. Track YOUR trend: if your cycle time is increasing sprint-on-sprint, that is the signal, not whether you are above or below an industry benchmark.