Cycle Time

The elapsed time between starting work on an issue and finishing it. Lower cycle time = faster, more predictable delivery.

What is cycle time?

Cycle time is the elapsed time between when a team starts working on a ticket (status moves to in progress) and when it's finished (status moves to done). It measures how long actual work takes once it begins.

Lower, more consistent cycle time = faster delivery and more predictable forecasts.

How to measure cycle time

  1. Record the timestamp when a ticket enters "In Progress".
  2. Record the timestamp when it enters "Done".
  3. Subtract. That's the cycle time for that ticket.
  4. Track the median (not the mean) across recent tickets — averages get distorted by long-tail outliers.

Cycle time vs lead time

  • Cycle time — start of work → done.
  • Lead time — when the request was made (or backlog created) → done. Lead time is always ≥ cycle time.

Lead time is what the customer feels. Cycle time is what the team controls.

Why cycle time matters

  • Faster feedback loops — short cycle time means smaller batches and faster learning.
  • Predictability — if 85% of tickets finish in under 5 days, you can confidently commit to a 5-day SLA.
  • Bottleneck signal — when cycle time grows, something in the workflow is breaking.

How to reduce cycle time

  • Smaller stories — break anything bigger than 5 points further down.
  • Apply WIP limits — fewer items in flight = each one finishes faster.
  • Faster code review — tickets parked in review usually dominate cycle time.

Related

Run sprints without a glossary tab open

SprintFlint sets up a working sprint with sensible defaults in 30 seconds — velocity, burndown, retros, and capacity all built in. Free for the first 300 tickets.