Software Delivery in a Minute
Cycle Time
Cycle time as a flow metric—how it differs from lead time and what it cannot answer alone.
In one sentence
Cycle time measures how long work items spend in an active delivery workflow between two process boundaries you define.
Why it matters
Teams use cycle time to spot queues in review, QA, and release. Confused with lead time or with individual performance, it becomes a weapon instead of a diagnostic.
How it works
- Name the start state (e.g., In Progress) and end state (e.g., Done/Deployed).
- Exclude idle backlog time if your definition is active-cycle only—and say so.
- Track medians and tails; averages hide stuck work.
- Investigate stages separately when the total rises.
Example
A ticket spends 2 days in review and 3 hours in deploy. Cycle time is dominated by review queue—not build minutes. Optimize the real wait.
What this proves
Cycle time proves elapsed workflow time between your chosen states for the items measured.
What this does not prove
Shorter cycle time does not prove better product outcomes or higher engineer worth. It does not include discovery time unless you define it that way.
Last reviewed 2026-09-06. Title for citation: Software Delivery in a Minute: Cycle Time.