Cycle Time in Project Management: Formula, Calculator + How to Use It (2026)
Cycle time is the clock that runs while a single work item is being worked on. Start it when the item enters "in progress" and stop it when the item is done. The number you get is the cycle time for that item. Average a few weeks of those numbers and you have a metric you can quote a client, a measurement you can defend in a stand-up, and the only honest answer to "how long does work like this usually take?"
The problem is that four different camps define cycle time four different ways, and most teams pick up the wrong one for their context. Lean manufacturing measures it per unit produced. Kanban software measures it per item on a board. DevOps measures it from first commit to production deploy. Generic agile blogs blur the three. This guide reconciles the four definitions, ships with a calculator that does the math, and explains how to set a cycle time SLA that holds up in front of a paying client.
Quick answer: what cycle time is
Cycle time is the elapsed time between the moment a work item starts being actively worked on and the moment it is delivered. For a kanban board, that means the timer starts when the card moves into "In progress" and stops when it moves into "Done." For each item you finish, you get one cycle time number. The cycle time of the team is the distribution of those numbers across a window of weeks, not a single average.
The reason cycle time matters is forecasting. Suppose 85% of design-review items finished in 9 days or fewer over the last six weeks. You can promise a client a 10-day turnaround on similar work with real evidence behind it. Without cycle time, every estimate is a guess.
Calculate your cycle time with Little's Law
Little's Law gives you average cycle time from two inputs you can pull off a board: average work in progress and throughput. The formula is simple. The calculator runs it for you and shows what happens if you cut WIP.
Cycle time calculator (Little's Law)
Enter how many work items the team has in progress, how many it finishes per week, and the target you want to hit. The calculator returns average cycle time and shows what changes if you cut WIP.
Items in progress at any moment.
Items completed per week, 4 to 6 week average.
What the team or client expects.
Current average cycle time
21days
Close to target. Look at WIP first.
What if WIP dropped?
Bar reflects the effect of the WIP cut. Baseline (no cut) is 21 days at WIP 12. The cut saves 5.2 days.
The calculator returns an average. Average is the right starting number when you are sizing a question or running a thought experiment. For client-facing commitments, replace average with a percentile, which the section on cycle time SLAs covers below.
Cycle time starts where the work starts.
Rock pairs chat with a task board, so the moment a card moves into "In progress" is the moment the timer starts. One flat price, unlimited users.
What is cycle time? Four definitions, reconciled
The cycle time confusion is real. Four communities define the metric four different ways, and treating their numbers as interchangeable is the most common source of bad estimates. Pick one definition, write the start and stop points down, and stay with it.
Martin Fowler's bliki post on cycle time makes the same point in different words. He calls it a "slippery" measurement because the start and stop points are not standardized, and he recommends naming them every time the metric is reported. That habit is the whole article in one move.
"Cycle time is one of those words used in lots of different ways, and it's important to be clear which one is meant whenever you encounter it." - Martin Fowler, martinfowler.com
Lean manufacturing definition
In a factory, cycle time is the time it takes to produce one unit. The clock runs while the unit is in the production process, and the number is most useful as an average across many identical units. This is the definition lean.org and Six Sigma references use. It assumes the work is homogeneous and that "one unit" means the same thing each time.
This definition does not translate to knowledge work. A landing page tweak and a brand refresh are not units of the same kind, so averaging the time they took produces a number that means nothing.
Kanban software definition
In kanban, cycle time is the elapsed time between the moment a single item enters the "in progress" column and the moment it leaves the "done" column. The clock runs per item, the number is recorded per item, and the team works with the distribution of those numbers rather than a single average. Daniel Vacanti formalized this approach in Actionable Agile Metrics for Predictability, paired with Little's Law and percentile-based forecasting.
This is the definition that works for agency and software teams. Per-item measurement handles heterogeneous work, the distribution surfaces variation honestly, and the math links cycle time, WIP, and throughput in a way the team can act on.
DevOps and DORA definition
The DORA research group, led by Nicole Forsgren, defines cycle time as the elapsed time from first commit on a feature to that feature reaching production. This is sometimes called "lead time for changes" inside DORA literature, which adds another layer of confusion. The DORA definition is the right one if the question is "how fast does our engineering team ship code." It is the wrong one if the question is "how fast does our team finish design tasks," because design work happens before any commit.
Generic agile definition
Most agile blogs use a vague version of the kanban definition without naming the start and stop points. "From work start to delivery" sounds clear until two team members disagree about when work "started." Was it the moment the ticket was created, the moment it was assigned, the moment the first line of code was written, or the moment it left the backlog? Each option gives a different number.
The fix is the Fowler rule: pick a start point, pick a stop point, and write both down on the team's wiki. After that, the conversation about cycle time is a conversation about the same number.
The cycle time formula and how to calculate it
There are two formulas worth knowing. One is Little's Law, which works for averages and is the math behind the calculator above. The other is the per-item formula, which works for percentile forecasting and is what you should report to clients.
Little's Law (for averages):
Average cycle time = Average WIP / Average throughput
If the team has 12 items in progress on average and finishes 4 items per week on average, average cycle time is 12 / 4 = 3 weeks, or 21 days. The same formula in reverse tells you the WIP you need to hit a target cycle time at a given throughput. Want 10-day cycle time at 4 items per week throughput? Carry no more than 5.7 items in progress at any moment.
Per-item formula (for percentiles):
Item cycle time = timestamp(done) - timestamp(in progress)
Record one number per item across at least four weeks. Plot the numbers on a histogram. The shape almost always has a long right tail. Pull the value at the 50th percentile (the median), the 85th percentile, and the 95th percentile. Those three numbers are the team's cycle time. The single average is a summary that hides the tail and burns the team when a client asks for a guarantee.
Four to six weeks of data is the typical minimum sample. Less than that and the percentiles move too much from one item to the next. More than three months and the data starts including team and process changes that no longer reflect today. Many teams pair cycle time tracking with sprint backlog reviews to spot the trend early.
Cycle time vs lead time
Lead time and cycle time are the metrics most often confused, partly because manufacturing, kanban, and DORA each define them slightly differently. The kanban definition is the one to use for service work.
Lead time is the elapsed time between the moment a customer makes a request and the moment they receive the delivery. The clock starts at request and stops at delivery. This is the number the client cares about, because it reflects their experience of waiting.
Cycle time is the elapsed time the team is actively working on the request. The clock starts when the item enters "in progress" and stops at delivery. This is the number the team can control, because it excludes the waiting period before work began.
Lead time is always greater than or equal to cycle time. The gap between them is queue time, which sits in the backlog. A team with a 5-day cycle time and a 20-day lead time has a queue problem, not a delivery problem. The fix is intake management, not faster execution. A team with a 5-day cycle time and a 6-day lead time has the inverse problem. The backlog is near empty and there is not enough work in queue to keep the team busy.
Don Reinertsen's Principles of Product Development Flow drives this point home. Cycle time is a dependent variable that follows from WIP and throughput. The independent variables, the ones you can actually move, are how much work you let in and how much capacity you have. Lengthening lead time on the front end often shortens cycle time on the back end. Taking longer to accept work cuts context switching, and the net experience for the client improves.
Cycle time vs takt time
Takt time is borrowed from lean manufacturing and rarely applies to service work, but the comparison keeps coming up in articles, so it earns a section.
Takt time is the pace of customer demand. If customers buy 80 units per 8-hour day, takt time is 6 minutes per unit. Production is balanced when one unit comes off the line every 6 minutes, no faster and no slower. Takt is a planning input, not a measurement output. It tells the team how fast they need to be, not how fast they are.
The reason takt does not translate cleanly to service work is that service demand is rarely steady or homogeneous. An agency might get one brand refresh request a quarter and twenty landing page tweaks a week. Computing a takt time across those would produce a meaningless number. Where takt occasionally applies in service work is at narrow process steps: how often does a content review need to clear the queue, given the inflow rate? That kind of constrained question is a valid use. "What is the agency's takt time?" is not.
Practical guidance: if a stakeholder asks for takt time and the team does service work, ask back what decision the number is supposed to inform. Most of the time, the question is really about throughput capacity, which is a different metric.
Cycle time vs throughput
This is the comparison most articles skip, even though it is the most useful pair for forecasting. Cycle time and throughput are two sides of the same flow. They are linked by Little's Law and they move together.
Throughput is the number of items the team finishes per unit of time. Items per week is the most common unit for software and agency work. Throughput is measured at the right edge of the board, not by counting active work.
The relationship matters because clients ask different questions of the same data. "When will this specific item be done?" is a cycle time question, and the answer is the 85th percentile of past items. "How many items can we get through this quarter?" is a throughput question, and the answer is the median weekly throughput multiplied by the number of weeks. Both numbers come from the same board export, but they answer different questions and surface different decisions.
The four-metric comparison below settles the differences in one view. Print it and stick it on the wall.
| Metric | What it measures | Clock starts | Clock stops | Common mistake |
|---|---|---|---|---|
| Cycle time | Active work duration per item | Item enters "in progress" | Item done | Averaging across mixed sizes instead of using percentiles |
| Lead time | Total customer wait | Request made | Delivered | Reporting it as cycle time and hiding queue problems |
| Takt time | Pace of customer demand | Not applicable | Not applicable | Treating it as a measured number instead of a planning input |
| Throughput | Items finished per period | Period start | Period end | Confusing with velocity (story points, not items) |
What "good" cycle time looks like for service work
There is no universal benchmark for cycle time. A bug fix should clear in hours; a brand strategy engagement should clear in months. What "good" looks like is a function of the work type, the team's cadence, and the client's expectation. The honest answer is that the team's last six weeks of cycle time data is the only benchmark that matters.
That said, three rules hold across most agency and product teams.
Use the 85th percentile, not the average. Daniel Vacanti's argument for percentile-based forecasting comes down to this: an average tells the client when half the items will be done. The other half take longer, sometimes much longer. An 85th percentile commitment means 17 out of 20 items will hit the date. That is the conversation a client actually wants to have. His books and the ProKanban resources lay out the math in detail.
"An average cycle time tells you almost nothing about how long any single piece of work will take. The variation around the average is where every interesting forecasting question lives." - Daniel Vacanti, paraphrased from Actionable Agile Metrics for Predictability
Track cycle time by work type, not in a single bucket. Design review, copy edit, and dev build are different work. Their cycle time distributions are different. Combining them into one number produces a percentile that is too wide for design work and too tight for dev. Tag items by type before measuring, and report cycle time per type.
Watch the trend more than the absolute number. A team whose 85th-percentile cycle time fell from 14 days to 9 days over a quarter is more useful to a client than a team holding a steady 12 days. The trend communicates that the team is learning. The absolute number, on its own, communicates only that the team finished some work.
Five steps to set a cycle time SLA
An SLA is a client-facing promise: "Items of type X are delivered within Y days." Setting one is straightforward once the team has cycle time data and has picked the kanban definition. The trap is committing to a number before the data exists.
- Define the start and stop points Pick the column on the board where the timer starts and the column where it stops. Write both on the team wiki. The most common choice is "in progress" to "done," but "ready for review" to "shipped" is also valid for some teams. Whatever you pick, do not change it once data collection starts.
- Instrument the board The board must record the timestamp when an item enters and leaves each column. Most kanban tools, including Rock, do this automatically through card history. Export the data to a spreadsheet at the end of each week.
- Collect four to six weeks of data Tag each completed item by work type before computing anything. Twenty items per type is the minimum that gives a stable percentile; fifty is better. Items that took an unusual path (paused, reopened) belong in a separate column for inspection, not in the SLA calculation.
- Compute median, 85th, and 95th percentiles For each work type, sort the cycle times ascending and pull the values at the 50th, 85th, and 95th percentile. The 85th percentile is what you commit to in the SLA. The 50th is what the team reports internally. The 95th is the worst-case to be transparent about.
- Write the SLA and the exceptions A clear SLA reads: "Design review items are delivered within 9 business days, measured from the moment the item enters review. Items requiring more than two rounds of revision fall outside this commitment." Name the type, the number, the start point, and what is excluded. Revisit the data quarterly and adjust.
Common cycle time pitfalls
Most teams that adopt cycle time measurement bounce off one of a small set of failure modes. The fixes are mechanical, not philosophical.
- Reporting the average instead of the percentile An average cycle time means half the items took longer. Commit to an average and you miss the date on every second engagement. Commit to the 85th percentile and you hit the date on 17 of every 20 items. The math is one column move in the spreadsheet and the credibility difference is enormous.
- Mixing work types in a single number A bug fix and a brand refresh share a board but not a distribution. Mixing them in one cycle time number gives you a percentile too loose to be useful for bugs and too tight to be honest about brand work. Tag work by type before measuring.
- Changing the start and stop points mid-quarter A team that quietly redefines "in progress" three weeks into data collection erases the trend they were trying to track. Once the definition is on the wiki, lock it for at least a quarter. If a change is needed, restart the data window from zero.
- Ignoring WIP and treating cycle time as the lever Cycle time is a dependent variable. The independent variables are WIP and throughput. Teams that try to push cycle time down without lowering WIP end up cutting corners on quality. The Reinertsen rule: move WIP first, watch cycle time follow.
- Treating one item as a signal A single item that took twice as long as the previous five is not a trend. It is one item. Forecast and SLA conversations require a window of at least 20 items per work type. Anything less and the team is reacting to noise.
- Optimizing the metric instead of the work Splitting tickets into smaller pieces to bring cycle time down is gaming the metric. The board looks healthier; the client still waits the same amount of total time. Watch lead time alongside cycle time to catch this pattern early.
What we recommend at Rock
Rock is not a dedicated kanban tool, but most of our customers run delivery work on the task board inside their space. That gives us a useful vantage point on how cycle time tracking actually plays out in service businesses.
The pattern that works is small. Each work type gets its own column flow on the board: backlog, in progress, in review, done. Cards move left to right and the card history records the timestamps. At the end of each week, the team lead exports the completed cards to a spreadsheet, tags them by type, and updates a rolling six-week view of median and 85th percentile cycle time. The whole exercise takes 20 minutes a week once the habit is in.
The conversation that matters happens at the weekly review. The team looks at the percentile by work type and asks one question: did anything cross the 85th percentile threshold this week, and if so, why? That single question catches scope creep, dependency bottlenecks, and queue problems before they show up in a client escalation. It is the cheapest early-warning system a delivery team can run.
For agency teams running several client backlogs in parallel, each client gets its own Rock space with its own board. The cycle time math runs separately per space because the work types are different per client. Combining clients into one number is a textbook example of the mixing-work-types pitfall.
Free resource: the Agile Sprint Planning template ships with backlog, in-progress, and done columns ready for cycle time tracking.
Frequently asked questions
What is cycle time in simple terms?
Cycle time is the time between when work on a single item starts and when that item is delivered. On a kanban board, the clock starts when the card moves into "in progress" and stops when it moves into "done." Each item produces one cycle time number, and the team works with the distribution of those numbers over a window of weeks.
What is the cycle time formula?
Two formulas matter. For averages, Little's Law gives cycle time = work in progress / throughput. For client commitments, per-item cycle time = timestamp(done) minus timestamp(in progress), reported as the 85th percentile of a window of items, not as an average.
What is the difference between cycle time and lead time?
Lead time measures the full customer wait, from the moment a request is made to the moment it is delivered. Cycle time measures only the active work, from the moment the item enters "in progress" to the moment it is delivered. Lead time minus cycle time is the queue time, which sits in the backlog before work begins.
Is cycle time the same as takt time?
No. Cycle time is a measurement of how long work actually takes. Takt time is a planning input that describes the pace of customer demand. Takt time tells you how fast the team needs to be; cycle time tells you how fast it is.
How do you calculate cycle time on a kanban board?
Record the timestamp when each card enters the "in progress" column and the timestamp when it enters "done." Subtract the two for each card. Collect four to six weeks of items, tag them by work type, and report the median, 85th, and 95th percentile per type. Most kanban tools record the timestamps automatically through card history.
What is a good cycle time for a software team?
There is no universal answer. A bug fix often clears in hours; a feature with backend changes can take weeks. The honest benchmark is the team's own last six weeks of data per work type. The trend matters more than the absolute number: a cycle time falling quarter over quarter signals a team that is learning.
Why use the 85th percentile instead of the average?
An average means half the items took longer. Committing to an average misses the date on every second engagement. Daniel Vacanti's argument in Actionable Agile Metrics is that the 85th percentile gives a commitment that holds for 17 of every 20 items, which is the only kind of forecast a client can use to plan.
Cycle time is one number per item, measured per work type, reported as a percentile across a window of weeks. Get the definition on the wiki, get the data into a spreadsheet, and the rest of the conversation with the client gets easier. Rock combines chat, tasks, and notes in one workspace. One flat price, unlimited users. Get started for free.
