Cycle time is how long a piece of work takes from an agreed start point to an agreed finish point. In knowledge work, that usually means from when someone starts on an item to when it is done. In manufacturing, it often means the time to complete one unit at a process step. Either way, it includes the waiting, handoffs and rework along the way, not just the hands-on effort.
This guide covers how to set the start and end points, the formula, how cycle time differs from lead time and takt time, why percentiles beat averages, what makes cycle time long and how to reduce it without hurting quality. For tools that track it from your board, see flow metrics tools.
Key takeaways
Cycle time = finish time − start time, for each item, using boundaries everyone agrees on.
Cycle time starts when work starts. Lead time starts when the customer asks. Takt time is the pace demand requires.
Most cycle time is waiting, not working, so the biggest gains come from queues and handoffs.
Use the median and the 85th percentile, not just the average.
Limiting work in progress is the most direct lever. Little's Law ties the two together.
What is cycle time?
Cycle time measures elapsed time, not effort. If a task enters 'in progress' on Monday morning and reaches 'done' on Thursday afternoon, its cycle time is three and a half days, even if only six hours of that were spent working on it. That is why it reflects what customers and downstream teams actually experience.
The term has two common meanings, so say which one you use. In flow-based work such as software, IT and office processes, it is the time from start to finish for one item. In manufacturing, it often means the time between units coming off a station, or the time one unit takes at a step. The glossary entry notes both.
Cycle time is a system measure. If every item waits two days for one approver, ten slow items do not mean ten slow people. They point at one queue.
Choose the start and end points
Without fixed boundaries, cycle time data is noise. Pick the pair that matches the decision you want to make:
Commitment to completion
From when the team commits to an item to when it is done. Common on kanban boards.
Active work to completion
From the first hands-on work to the definition of done. Good for managing a team's execution.
Request to delivery
From when the customer asks to when they have it. This is lead time, and it includes upstream waiting.
Process start to process finish
A unit entering and leaving one production step.
Development to release
From starting to build to the change being live, common in software.
Write the definition down and keep it. Changing where 'start' sits halfway through a quarter makes the trend meaningless.
Cycle time vs lead time vs takt time
The three are related but answer different questions:
| Metric | The question it answers | Example |
|---|---|---|
| Cycle time | How long does work take once it starts? | A design review takes four working days from start to approval |
| Lead time | How long does the requester wait overall? | A change request takes twelve days from submission to release |
| Takt time | What pace does demand require? | A line must finish one unit every six minutes to meet orders |
| Throughput | How many items finish in a period? | A team completes 25 tickets a week |
Cycle time
How long does work take once it starts?
Example: A design review takes four working days from start to approval
Lead time
How long does the requester wait overall?
Example: A change request takes twelve days from submission to release
Takt time
What pace does demand require?
Example: A line must finish one unit every six minutes to meet orders
Throughput
How many items finish in a period?
Example: A team completes 25 tickets a week
Takt time is set by demand and cycle time by the process. If takt is six minutes and the step's cycle time is eight, the step cannot keep up without more capacity or improvement. The takt time calculator and takt time page cover that side.
How to calculate cycle time
For each finished item: cycle time = finish time − start time. Measure in hours, working days or calendar days, whichever matches the rhythm of the work, and stay consistent.
For a whole system, Little's Law links the averages: average cycle time = average work in progress ÷ average throughput. In an illustrative case, a team with 12 items in progress that finishes 4 a week has an average cycle time of about 3 weeks. Halve the work in progress at the same throughput and the average cycle time halves too.
The law holds for averages over a stable period, so use it to understand the system, not to forecast one item. The guide on why limiting WIP makes teams faster explains when it applies.
Why averages mislead: use percentiles
Averages hide spread. In an illustrative set of ten items, nine finish in 2 days and one takes 30. The average is 4.8 days, which describes none of them.
The median (the middle value) is 2 days here and is less swayed by outliers. The 85th percentile is the time within which 85% of items finish. It is a fair basis for a service expectation: 'most requests like this finish within 10 days' is a promise you can keep.
A cycle time scatterplot, one dot per finished item, shows the spread at a glance. It also shows which work types sit far above the rest.
Fields worth recording
Start and finish dates are the minimum. A few more fields explain why cycle time behaves the way it does:
Item ID and work type
Defect, feature, request, change order or unit, so comparisons are fair.
Start and finish timestamps
At the boundaries you agreed.
Blocked time and reason
Missing information, approval, dependency or equipment.
Rework flag
Whether the item went back a step.
Priority class
Standard, urgent or expedited.
Batch size
In manufacturing and batch-based office work.
Step owner
The team or station at each stage.
Cycle time in different settings
The idea is the same everywhere, but the levers change:
Manufacturing
Time at a station or through a line. In injection molding, cooling often dominates the cycle, and speeding the machine can cause warping. Study it with standard work, changeovers and line balance.
Software
Time from development start to release. Long cycle times usually come from large items, overloaded reviewers, test environment waits and big release batches.
Office and service
Approvals, onboarding, claims and tickets. The work sits in inboxes and bounces between teams, so the delays are invisible until someone measures each stage.
What makes cycle time long
Long cycle times usually have several causes at once:
Too much work in progress
When everything starts, everything waits.
Large batches
Feedback comes late and queues grow.
Unclear requirements
Time lost clarifying what should have been settled up front.
Approval bottlenecks
Work waits for one person or committee.
Specialist constraints
Only a few people can do a critical step.
Rework
Errors send items back through earlier steps.
Context switching
People juggle too many items and lose momentum.
Dependencies
Other teams, vendors or customers hold things up.
Context switching alone is costly. Psychologist David Meyer, whose task-switching research the American Psychological Association summarizes, has said that even brief mental blocks from shifting between tasks can cost as much as 40% of someone's productive time.
Reducing cycle time without hurting quality
The goal is fewer waits and less rework, not people rushing. A sequence that works:
- 1
Fix the boundaries. Decide exactly what you are measuring.
- 2
Collect a baseline. Enough finished items to see the usual pattern, not one bad example.
- 3
Separate work types. Routine, complex and urgent work need their own numbers.
- 4
Map the flow. Every step, queue, approval, handoff and rework loop.
- 5
Find the constraint. The step where work piles up or waits longest.
- 6
Limit work in progress. Stop starting more than the system can finish. See WIP limits.
- 7
Improve what comes in. Clear request forms, acceptance criteria or readiness checks.
- 8
Simplify handoffs. Remove extra approvals, duplicate data entry and unclear ownership.
- 9
Test in small steps. Change one or two things, then measure again.
- 10
Watch quality. Faster work that creates defects has not improved anything.
Software research points the same way. Google's 2024 DORA report found that rising AI adoption came with an estimated 1.5% drop in delivery throughput and a 7.2% drop in delivery stability, and the DORA team concluded that basics such as small batch sizes and robust testing remain crucial.
Good tracking habits
The number is only as good as the habits behind it:
- Move cards when work changes state: Not at the end of the week.
- Make blocked work visible: With a reason, an owner and a next step.
- Review aging work first: Before starting anything new.
- Tag work types: So comparisons are fair.
- Forecast from finished items: And intervene on items still in progress.
- Discuss outliers without blame: So people keep reporting honestly.
Common cycle time mistakes
A few habits undermine the measure:
- 1
Comparing unlike work. A two-hour ticket and a six-week change should not share one average.
- 2
Measuring too late. Starting only once delays are severe hides how they built up.
- 3
Treating faster as always better. Some work needs deliberate review, such as safety-critical or regulated steps.
- 4
Ignoring demand. Cycle time that is fine at normal volume grows when intake doubles and capacity does not.
- 5
Using it against individuals. A measure that makes people defensive gets gamed.
Predictability matters to sponsors. The Project Management Institute's 2026 Pulse of the Profession found that 31% of complex projects fail to achieve the full scope of their intended benefits. Stable, known cycle times make plans easier to keep.
Frequently asked questions
How do you calculate cycle time?
What is the difference between cycle time and lead time?
What is the difference between cycle time and takt time?
How do you reduce cycle time?
Choosing Flow Metrics Tools?
Read the buying guide: what to look for, mistakes to avoid and questions to ask vendors.
Related guides
- WIP limits: why limiting work in progress makes teams fasterWhat WIP limits are, why limiting work in progress shortens lead time under Little's Law, how to set a first WIP limit and how to handle urgent work.Read the guide
- Actionable metrics vs vanity metrics, with examplesActionable metrics explained: how they differ from vanity metrics, the three A's, examples by team, flow metrics for predictability and a checklist.Read the guide
- Cumulative flow diagram: how to read a CFDHow to read a cumulative flow diagram: bands, slopes and the top line, reading WIP and cycle time off the chart, common patterns, a sprint example and Jira tips.Read the guide
- Cohort analysis: how to build and read a retention tableCohort analysis explained: cohort types, starting events, retention and churn metrics, how to read a retention table, a spreadsheet method and mistakes.Read the guide
Sources
Books and papers show their publication year. Web pages show the month we last checked them.
- 1.Daniel S. Vacanti, Actionable Agile Metrics for Predictability (ActionableAgile Press, 2015)
- 2.John D. C. Little, A Proof for the Queuing Formula: L = λW (Operations Research 9(3), 1961)
- 3.Donald G. Reinertsen, The Principles of Product Development Flow (Celeritas Publishing, 2009)
- 4.David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business (Blue Hole Press, 2010)
- 5.American Psychological Association, Multitasking: Switching costs (apa.org, March 2006, checked October 2026)
- 6.Google Cloud, Announcing the 2024 DORA report (cloud.google.com, October 2024)
- 7.DORA, Accelerate State of DevOps Report 2024 (dora.dev, checked October 2026)
- 8.Project Management Institute, Pulse of the Profession 2026 (pmi.org, 2026)