Cycle Time: Formula, Little's Law & Lead Time [2026]
A. Togay Koralturk, Best-Selling PMP Author
Last updated on July 29, 2026
11 min read
Two teams can look equally busy and deliver at wildly different speeds — the difference is usually cycle time. It's the metric that answers the question every stakeholder eventually asks: "once you start something, how long until it's actually done?" Borrowed from manufacturing and now central to agile flow, cycle time turns a vague sense of "we're slow" into a number you can measure, forecast, and improve. This guide explains cycle time in full — the formula, how it differs from lead and takt time, how Little's Law ties it to work in progress and throughput, how to reduce it, and how it appears on the PMP and CAPM exams.
What is cycle time?
Cycle time is the amount of time it takes to complete one work item once active work on it has begun — measured from the moment it starts being worked on to the moment it is finished. It is a measure of how fast work actually moves through a team once it's underway, and it is one of the fundamental flow metrics in Kanban and lean.
The concept comes from manufacturing, where cycle time is the time to produce a single unit, and it has carried over almost unchanged into agile and knowledge work. The key word is active: time an item spent sitting in a backlog or queue before anyone touched it isn't part of cycle time — that waiting belongs to lead time, which we'll get to shortly. Because it isolates the "doing" part of the work, cycle time is the metric teams watch to understand and improve their actual delivery speed.
The cycle time formula
How you calculate cycle time depends on whether you're counting identical units on a production line or varied work items on a board.
In manufacturing, where units are interchangeable, cycle time is calculated across a batch:
> Cycle time = net production time ÷ number of units produced
So a line that runs for 400 productive minutes and turns out 200 units has a cycle time of 2 minutes per unit. In agile and knowledge work, where every item is different, cycle time is measured per item rather than across a batch. Because those per-item times vary, teams don't rely on a single number: they track the average cycle time, or better, a percentile (for example, an 85th-percentile cycle time of six days means 85% of items finish within six days). Percentiles are more useful for forecasting because they express how reliably, not just how quickly, work gets done.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
Cycle time vs. lead time
Cycle time and lead time are the most commonly confused flow metrics, and the difference is entirely about where the clock starts. Lead time measures the whole wait from the customer's point of view — from when a request is made to when it's delivered. Cycle time measures only the active-work portion. Lead time therefore includes cycle time, plus all the waiting before work begins.
| Lead time | Cycle time | |
|---|---|---|
| Clock starts | When the request is made | When work actively begins |
| Clock stops | When it's delivered | When the item is done |
| Includes waiting? | Yes — queue time before work starts | No — active work only |
| Whose view | The customer's total wait | The team's working speed |
The practical upshot: a team can have a short cycle time but a long lead time if items sit in the backlog for weeks before anyone picks them up. Improving delivery often means attacking the waiting — the gap between the two — as much as the work itself.
Cycle time vs. takt time
Takt time is a third metric that often appears alongside the other two, but it's a different kind of number. Takt time is the pace you need to hit to keep up with customer demand — calculated as the available working time divided by the number of units customers require in that time. Where cycle time is something you measure, takt time is a target rhythm you aim for.
> Takt time = available production time ÷ customer demand
The relationship between them is the useful part. To meet demand, a team's cycle time must be at or below its takt time: if customers need one unit every 5 minutes (takt time) but each unit takes 8 minutes to produce (cycle time), the team can't keep up and a backlog builds. If cycle time is comfortably below takt time, the team is keeping pace with room to spare. Takt time is most at home in manufacturing with steady demand, but the logic — compare your delivery speed to the demand you need to meet — applies to any team.
Little's Law: cycle time, WIP, and throughput
Cycle time doesn't stand alone — it's mathematically linked to two other flow metrics by Little's Law, one of the most useful results a team can know. Originally from queuing theory, in flow terms it states:
> Average work in progress = average throughput × average cycle time
Rearranged to solve for the metric we care about:
> Average cycle time = work in progress ÷ throughput
Here work in progress (WIP) is how many items are being worked on at once, and throughput is the rate at which items are completed (items per day or per week). The law's power is in what it implies: if throughput stays roughly constant, the more work you have in progress, the longer your cycle time gets. Piling on more simultaneous work doesn't make things finish faster — it makes each item take longer, because attention and capacity are split.
This is the quantitative reason behind the Kanban mantra "stop starting, start finishing" and the practice of limiting WIP. Cutting the number of items in progress, without changing anything else, directly shortens cycle time. All three metrics can be read straight off a cumulative flow diagram: the thickness of the in-progress band is WIP, the slope of the done line is throughput, and the horizontal distance across the bands is cycle time.
Why cycle time matters
Cycle time matters because it turns "how long will this take?" from a guess into a forecast. A team with a stable, well-understood cycle time can make reliable delivery predictions — "most items ship within a week" — without the elaborate estimation rituals that eat into delivery. Predictability, not just speed, is the prize.
Its benefits compound. A short cycle time means faster feedback: work reaches customers sooner, so the team learns what's valuable and corrects course quickly. It signals healthy flow: a rising cycle time is an early warning of bottlenecks or too much WIP, often visible before anything else goes wrong. And it enables forecasting: because cycle time, WIP, and throughput are linked by Little's Law, a team that tracks them can forecast delivery empirically from its own data rather than from optimistic estimates. For flow-based approaches like Kanban and scrumban, cycle time is the single most important number to watch — the pulse of how work actually moves.
How to reduce cycle time
Reducing cycle time is mostly about removing the delays and overload that slow work down, rather than pushing people to work faster. The highest-leverage moves:
- Limit work in progress. The most direct lever, straight from Little's Law: fewer items in progress means each finishes sooner. Cap how much the team starts before finishing what's underway.
- Remove bottlenecks. Find the stage where work piles up — the constraint that sets the pace of the whole system — and relieve it. Everything upstream of a bottleneck just grows the queue.
- Reduce batch and item size. Smaller items flow faster and more predictably than large ones. Breaking work down, a core part of lean project management, shrinks cycle time and exposes problems sooner.
- Cut waiting and handoffs. Time spent waiting for approvals, reviews, or another team is often the biggest hidden chunk of cycle time. Streamlining handoffs attacks it directly.
- Clear blockers fast. Make impediments visible and resolve them quickly; a blocked item sitting idle is pure cycle-time inflation.
The theme running through all of these is flow over utilization: a team optimized to keep everyone 100% busy usually has worse cycle time than one that deliberately leaves slack to keep work moving. Finishing beats starting.
Cycle Time on the PMP® and CAPM® Exams
Because the current PMP exam covers agile and hybrid delivery in depth, cycle time appears as a flow metric used in Kanban and lean-oriented work. The facts to lock in: cycle time measures active work from start to done, lead time measures the whole wait from request to delivery, and Little's Law links cycle time to WIP and throughput. Expect the exam to test the lead-versus-cycle distinction and the idea that limiting WIP reduces cycle time.
Situational questions tend to describe a team whose delivery is slowing while everyone is busy starting new work, and reward recognizing that excess WIP — not a lack of effort — is the cause, with limiting WIP as the fix. Others may ask you to read flow metrics off a cumulative flow diagram or to forecast using throughput. The underlying idea the exam rewards is empirical management: measure how work actually flows and improve the system, rather than pressure individuals. Our PMP Complete Study Guide, the most complete on the market, covers flow metrics and agile forecasting as the exam frames them.
PMP Practice Question: Cycle Time
A Kanban team's average cycle time has climbed steadily for two months and delivery has slowed, even though everyone is visibly busy. The board shows why the project manager is worried: team members keep starting new items while older ones sit unfinished, work in progress has grown sharply, and throughput has stayed roughly flat. A stakeholder, watching deadlines slip, proposes funding two additional developers to speed things up.
What should the project manager do next?
a) Accept the stakeholder's proposal, since added capacity raises throughput and shorter cycle times will follow.
b) Introduce work-in-progress limits so new items are started only as current ones finish.
c) Have the team swarm the oldest unfinished items until the built-up work in progress is cleared, then resume normal working.
d) Break the work into smaller items so each one finishes faster and the cycle-time numbers come down.
Correct answer: B.
Rationale: Little's Law reads the board directly: average cycle time equals WIP divided by throughput, and here WIP grew while throughput stayed flat, so cycle time had to rise. Only a standing WIP limit changes that mechanism — it caps the numerator permanently and converts the team's habit from starting to finishing. A one-time swarm on old items lowers WIP briefly, but with the starting habit intact the pile rebuilds within weeks; added developers attack the denominator at real cost while leaving the WIP growth untouched (and often raise it, since more people can start more items); and smaller items shrink the measurement of each item without limiting how many are open at once, which is the variable actually driving the slowdown. To drill this kind of flow-metric judgment, work through our PMP practice exams or, at the entry level, our CAPM practice exams.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
Frequently asked questions
What is cycle time?
Cycle time is the time it takes to complete one work item once active work on it has begun — measured from when the item enters "in progress" to when it reaches "done." It captures how fast work actually moves once it's underway, excluding any time the item spent waiting in a queue beforehand. It is a core flow metric in Kanban and lean.
What is the cycle time formula?
In manufacturing, cycle time = net production time ÷ number of units produced, giving the time per unit. In agile and knowledge work, cycle time is measured per item as the elapsed time from when work starts to when it's done, and is usually reported as an average or a percentile — for example, an 85th-percentile cycle time of six days means 85% of items finish within six days.
What is the difference between cycle time and lead time?
Lead time measures the whole wait from the customer's perspective — from when a request is made to when it's delivered. Cycle time measures only the active-work portion — from when the team starts working on the item to when it's done. Lead time includes cycle time plus all the waiting before work begins, so lead time is always equal to or longer than cycle time.
What is the difference between cycle time and takt time?
Cycle time is how long it actually takes to complete a unit or item, a value you measure. Takt time is the pace required to keep up with customer demand — available working time divided by demand — a target you aim for. To meet demand, cycle time must be at or below takt time; if cycle time exceeds takt time, the team can't keep up and a backlog forms.
What is Little's Law?
Little's Law states that average work in progress equals average throughput multiplied by average cycle time. Rearranged, average cycle time = work in progress ÷ throughput. It means that if throughput stays constant, having more work in progress lengthens cycle time. This is the mathematical reason teams limit work in progress: cutting WIP directly shortens cycle time.
How do you reduce cycle time?
The most effective ways to reduce cycle time are to limit work in progress, remove bottlenecks, reduce batch and item size, cut waiting and handoffs, and clear blockers quickly. The common theme is prioritizing flow over keeping everyone maximally busy — a team that finishes work before starting more, and leaves some slack, usually has a shorter cycle time than one running at full utilization.
Is cycle time on the PMP exam?
Yes. The current PMP exam covers agile and hybrid approaches heavily, and cycle time appears as a Kanban flow metric. You are expected to know how it differs from lead time, how Little's Law links it to work in progress and throughput, and to recognize that limiting WIP reduces cycle time — often in scenarios where a busy team's delivery is slowing.
Is cycle time on the CAPM exam?
Yes. The CAPM covers agile flow metrics including cycle time, usually a little more directly than the PMP — often testing the definition, the difference between cycle and lead time, or the basic idea of Little's Law. Because the CAPM is scenario-based, you should also be ready to identify when rising work in progress is causing cycle time to increase.
Burnup Chart in Agile: Example & vs. Burndown [2026]
A burnup chart plots work completed and total scope as two lines, so scope stays visible. An example, how to read it, burnup vs. burndown, and the PMP exam.
Agile Release Planning: Process & Levels [2026]
Agile release planning maps features across sprints toward a release. The planning levels, date vs. scope, how to forecast with velocity, and PMP exam tips.
Minimum Viable Product (MVP): Meaning & Examples [2026]
A minimum viable product (MVP) is the simplest usable version of a product, built to learn from customers. MVP vs. prototype, examples, and PMP exam tips.
