Cycle Time | Agile Scrum Master
Cycle Time is the elapsed time from when work starts on an item to when it is finished according to the team's done policy, and it is a key flow metric for improving delivery capability. It helps teams identify queues, bottlenecks, and variability, and to design experiments such as limiting WIP, improving slicing, or strengthening automation. Key elements: clear start and finish points, consistent done policy, distribution and variability (not averages only), and use for system improvement rather than performance pressure.
Cycle Time and what it measures
Cycle Time measures how long it takes to finish a work item once work has started on it, using a clear “start” point and a clear “finished” point. Cycle Time is a flow metric: it describes the behavior of a system over time rather than the productivity of individuals. It focuses on the “active work” phase, excluding any waiting time before work starts. By tracking Cycle Time, teams gain insight into delivery responsiveness, workflow friction, and how quickly they can turn learning into a usable increment.
Cycle Time is only meaningful when the finish point reflects usable value according to the team’s done policy. If “done” means “implemented but not verified,” the metric understates the real time to outcomes and hides queues and rework. Use it as an empirical input: make the measurement policy transparent, inspect the distribution and work item aging, and adapt WIP limits, slicing, and automation based on what the data and observations show.
Defining start and finish for Cycle Time
Cycle Time becomes actionable when start and finish points are consistent. Teams often define “start” as when an item enters an “in progress” state and “finish” as when it enters a “done” state that reflects usability.
Common definitions include:
- Start point - Item moves from “ready” to “in progress,” indicating active work has begun.
- Finish point - Item meets the done policy and is in a usable state, not awaiting hidden work.
- Measurement unit - Expressed in hours or days, depending on workflow granularity and decision needs.
- Item unit - A consistent work item type, such as a Product Backlog item, story, or ticket.
- Scope boundaries - Clear rules for splitting, merging, or reclassifying items so data stays comparable.
Without these definitions, Cycle Time data becomes noisy and disputed. The aim is consistency that enables learning and improvement, not measurement perfection.
How to Calculate Cycle Time
- Define start and end criteria - Agree on what constitutes the beginning and completion of work.
- Track work items - Record timestamps for start and finish points using a board or delivery tool.
- Calculate duration - Subtract the start time from the finish time for each work item.
- Analyze trends - Inspect distributions and percentiles over time and relate changes to system conditions.
Interpreting Cycle Time Data
- Shorter Cycle Time - Can indicate smoother flow and faster feedback if usability and quality remain strong.
- Longer Cycle Time - Often signals queues, excessive WIP, dependencies, interruptions, or rework.
- Consistency - Stable percentiles suggest predictability; widening spread indicates rising risk and variability.
Using distributions rather than averages
Cycle Time is typically variable, and the variability matters. Averages hide risk: two systems can have the same average Cycle Time but very different predictability. Percentiles and trends are usually more informative for decisions, for example using the 85th or 95th percentile as a service expectation and checking whether it improves after a workflow change.
Practical ways to use Cycle Time include tracking a rolling distribution, watching work item aging to spot stuck items early, and comparing before-and-after distributions for specific experiments. When Cycle Time suddenly widens, it often indicates increased WIP, more dependencies, more interruptions, or larger batch sizes. For forecasting, teams often combine Cycle Time and Throughput evidence to communicate a range rather than a single date.
What influences Cycle Time
Cycle Time is influenced by both processing time (time spent actively working) and waiting time (time spent blocked, queued, or awaiting review). In knowledge work, waiting time often dominates, which is why system constraints and policies matter more than pushing individuals to go faster.
Common drivers of Cycle Time include:
- Work in progress - Higher WIP increases queues and context switching, typically increasing Cycle Time.
- Batch size - Larger items take longer and create more variability than smaller, well-sliced items.
- Dependencies - External approvals, shared components, and cross-team coordination add waiting.
- Quality practices - Weak automation and late testing increase rework and extend Cycle Time.
- Policies and handoffs - Complex workflow states and specialist queues create delay.
Improving Cycle Time usually means reducing waiting and variability. That is why it works best as a system metric interpreted with WIP, Throughput, and quality evidence.
Improving Cycle Time through experiments
Cycle Time improves when teams change how work flows. Effective experiments are small, timeboxed, and measured by shifts in the Cycle Time distribution and aging patterns, not by chasing a single number. The intent is to reduce queues and rework while keeping the done policy honest.
Common improvement experiments include:
- Limit WIP - Reduce concurrent work to shorten queues and increase finishing rate.
- Slice thinner - Break items into smaller value slices that can be finished quickly and integrated safely.
- Reduce review delays - Change review policies (pairing, mobbing, smaller PRs) to shorten waiting for feedback.
- Strengthen automation - Improve CI, tests, and deployment to reduce rework and late-stage delays.
- Swarm on aging work - Prioritize finishing stuck items over starting new work to reduce aging and stabilize flow.
- Refine backlog items - Make items small and clear before starting to reduce thrash and mid-flight rework.
- Address bottlenecks - Identify constraints with flow signals and remove them one at a time.
Cycle Time can be inspected in Sprint Retrospective as one signal of flow health. Use it as a learning loop: name the system constraint, run a small change, and inspect whether predictability and quality improved.
Common misuses and guardrails
Cycle Time is easily gamed if used as a performance target. Misuse usually shows up as redefining “start” or “done,” splitting work unnaturally, or pressuring people to “close tickets” while quality and usability degrade.
Common misuses and how to prevent them:
- Turning it into a target - Looks like demanding shorter times without changing constraints; it drives gaming and shortcuts. Use it to surface queues and choose system experiments.
- Shifting start or done - Looks like moving timestamps or redefining states to “improve” the metric; it breaks transparency. Keep start/finish policies explicit and record any policy changes.
- Optimizing locally - Looks like rushing easy items while hard items age; it hurts outcomes and predictability. Track aging and percentiles and swarm to finish stuck work.
- Ignoring quality - Looks like faster completion with more defects and rework; it creates future delays. Pair Cycle Time with quality evidence and keep the done policy strict.
- Using it to judge people - Looks like ranking individuals or teams; it hides constraints and reduces learning. Treat it as a system measure and improve workflow policies instead.
Relationship with other flow measures
Cycle Time is often discussed alongside Lead Time, WIP, and Throughput. Cycle Time focuses on the period after work starts. Lead Time includes the waiting time before work starts, which is often the biggest source of customer delay.
Using Cycle Time well means treating it as a diagnostic and improvement lens. If a team reduces Cycle Time but customers still wait a long time, intake, prioritization, or upstream discovery queues may be the real constraint. Interpret Cycle Time within the broader value stream and combine it with Throughput, WIP, and quality signals to make trade-offs explicit.
Cycle Time is the elapsed time from when a work item starts to when it is finished per the team's done policy, used to improve flow and predictability