Cycle time is the amount of time it takes to complete a unit of work, measured from the moment someone actually starts working on it to the moment it's finished and ready for the customer or the next stage of the process. In software teams, that usually means the time from when an engineer picks up a ticket and starts coding to when that code is deployed and working in production. It's a narrower measure than it sounds at first, because it deliberately excludes the time work spent waiting in a backlog before anyone touched it; it's about how long active work takes once it begins, not how long an idea has existed.
The reason cycle time exists as a metric is that teams needed a way to answer a very practical question: once we commit to doing something, how long does it actually take us to get it done? Story points and sprint velocity answer a different question, roughly how much work a team estimates it can complete in a fixed period, but they say very little about how long any individual piece of work actually takes to move through the system, and they're notoriously inconsistent across teams because story point scales aren't standardized. Cycle time sidesteps a lot of that ambiguity by measuring actual elapsed time, in days or hours, which is a unit everyone understands the same way regardless of how a particular team estimates its work.
What distinguishes cycle time from the closely related idea of lead time is the starting point of the clock. Lead time typically starts when a request or idea first enters the system, say when a ticket is created or a customer submits a request, and runs until that work is delivered. Cycle time starts later, when work actually begins, and excludes the time a piece of work sat waiting in a queue before anyone picked it up. This distinction matters because a long lead time with a short cycle time tells a very different story than a long lead time with a long cycle time: the first points to a prioritization or queuing problem, work sits around before anyone starts it, while the second points to a problem in how the work itself gets done once someone's actively on it.
By 2026, cycle time has become one of the most commonly tracked engineering metrics, built into most modern project management and engineering analytics tools, often broken down by stage, coding, review, testing, deployment, so teams can see exactly where time within the cycle is actually going rather than just the aggregate number. The growing sophistication in how the metric gets broken down reflects a maturing understanding that the total cycle time number is useful as a headline figure, but the real diagnostic value comes from seeing which stage of that cycle is actually consuming the most time.
This page covers what cycle time measures and how teams typically define its start and end points, how it differs from lead time and sprint velocity, what actually drives cycle time up or down inside a real engineering team, where it's a useful metric and where it gets misapplied or gamed, and how a team can use it to genuinely improve delivery speed rather than just decorate a dashboard. The durable idea is that shorter cycle time, achieved honestly rather than through gaming the definition, correlates strongly with a team's ability to learn fast, respond to customers, and reduce the risk baked into any individual change.
The confusion between cycle time and lead time is common enough that it's worth being precise about it early. Lead time, in most software team usage, is the clock that starts when a piece of work is requested or created, a ticket gets filed, a customer submits a request, and runs until that work is delivered. Cycle time is the clock that starts once someone actually begins working on it. If a ticket sits in a backlog for three weeks before an engineer picks it up, and then takes two days to complete once they start, the lead time is roughly three weeks and two days, while the cycle time is two days.
This distinction isn't pedantic, it changes what conclusions a team draws from a slow-feeling delivery process. A team with a long lead time but a short cycle time has a prioritization and queuing problem: work isn't getting picked up fast enough, probably because there's too much work in progress already, or priorities aren't clear enough for engineers to know what to pick up next. A team with both a long lead time and a long cycle time has a deeper problem, because even once work starts, it drags, which usually points to issues like unclear requirements, work that's too large and should be broken down, or friction in code review and testing.
Sprint velocity measures something different again: the amount of estimated work, usually in story points, a team completes within a fixed time box like a two-week sprint. Velocity is useful for a team's own sprint planning, roughly how much can we commit to next sprint based on recent history, but it's a poor tool for anything beyond that narrow purpose, because story point scales are subjective and vary wildly between teams, which makes velocity meaningless as a cross-team comparison and easy to inflate by re-estimating the same work with bigger numbers over time.
Cycle time avoids most of that gaming risk because it's measured in actual time, hours or days, a unit that doesn't bend to a team's internal estimation habits. That said, it isn't immune to distortion either. Teams can shrink cycle time on paper by artificially narrowing what counts as the start of work, or by breaking large pieces of work into so many small tickets that each individual cycle time looks great while the actual feature still takes weeks to reach a customer. The metric is honest about what it measures, but what it measures still depends on how consistently a team defines "started" and "done."
A related but distinct concept worth naming is throughput, which counts how many items a team completes in a given period rather than how long any single item takes. A team can improve throughput without improving cycle time at all, simply by having more people working in parallel, and a team can improve cycle time without changing throughput much, by clearing the same amount of work faster per item but not necessarily more of it overall. The two metrics answer different questions, and a team focused only on one can end up with a distorted view of whether it's actually getting better at delivering value, since a healthy team generally wants both figures moving in a good direction together, not one improving at the expense of the other.
The single biggest lever most teams don't appreciate early on is work-in-progress limits, meaning how many things a team or an individual engineer is actively working on at once. Cycle time tends to blow up not because any individual task is hard, but because engineers are context-switching between four or five things at once, each one progressing slowly because attention is split. Limiting how much work is in flight at any given time, even informally, tends to shrink cycle time noticeably, because tasks get focused attention and move through the system faster even though the total amount of work being done hasn't necessarily changed.
Batch size is the second major driver. A ticket that represents two days of focused coding work moves through review, testing, and deployment much faster than a ticket that represents two weeks of tangled, interdependent changes. Large batches take longer to review carefully, they're more likely to trigger a back-and-forth in code review because there's simply more surface area for a reviewer to have questions about, and they're riskier to test and deploy because more things changed at once. Teams that get disciplined about breaking work into small, independently shippable pieces almost always see their cycle time drop, not because the work itself got easier, but because each piece moving through the pipeline is smaller and simpler to move.
Review and approval friction is where cycle time quietly dies in a lot of organizations. A piece of code that took four hours to write can sit for two days waiting for a reviewer to have time to look at it, and that waiting time counts fully against cycle time even though no one is actively doing anything wrong. Teams that treat code review as a first-class, time-boxed responsibility, rather than something squeezed in between other priorities, tend to see a disproportionate improvement in cycle time relative to the effort involved, because review wait time is often the single largest chunk of the total cycle for a piece of work.
Deployment and release friction is the last major lever, and it's often invisible until someone actually measures it. If getting a finished, reviewed change into production requires a manual QA sign-off, a scheduled release window, and approval from three different people, that process can add days to cycle time regardless of how fast the actual coding and review happened. Teams that invest in automated testing, continuous deployment, and feature flags that decouple deploying code from releasing a feature to users tend to see cycle time drop sharply, because the last mile of getting a change live stops being the bottleneck it often quietly becomes.
Dependencies on other teams are a less obvious driver, but they tend to produce the longest and most frustrating cycle times of all, because the waiting happens outside the team's own control. A ticket that requires a schema change from a data platform team, or an API contract update from a separate services team, sits idle waiting on someone else's priorities, and that idle time counts fully against cycle time even though the blocked team isn't doing anything wrong by working on its own roadmap. Teams that reduce this kind of cross-team dependency, through clearer API contracts negotiated ahead of time, or through architectural boundaries that let one team ship independently more often, tend to see some of the largest gains in cycle time, because they remove waiting time that no amount of internal process improvement could have touched.
Getting cycle time measurement right starts with a clear, consistent definition of the start and end points that everyone on the team actually agrees on and follows. "Started" might mean when a ticket moves into an "in progress" column, or when the first commit against it lands. "Done" might mean when code is merged, or when it's actually deployed and live. Neither choice is inherently correct, but the team needs to pick one and apply it consistently, because a metric that means something different from week to week or engineer to engineer isn't measuring anything reliable at all.
Breaking the total cycle time into stages, time in development, time waiting for review, time in review, time waiting for deployment, time in testing, gives far more diagnostic value than the single aggregate number. A team might discover their total cycle time is five days, which sounds fine until the stage breakdown reveals that four of those five days are spent waiting for a code review, not actually coding, reviewing, or testing. That breakdown points directly at where to invest improvement effort, whereas the aggregate number alone would have left the team guessing.
Averages hide more than they reveal with cycle time, because the distribution tends to be skewed by a small number of tickets that take unusually long due to blockers, unclear requirements, or dependencies on other teams. Looking at the median cycle time, and separately looking at outliers to understand why a handful of tickets took dramatically longer than the rest, tells a much more useful story than a single average number that a few bad outliers can distort significantly.
The team also needs to watch for the ways this metric gets gamed, intentionally or not. If cycle time becomes something individuals are evaluated on directly, engineers have an incentive to break work into artificially small tickets that look fast individually while the actual feature the customer cares about still takes just as long to fully land. The healthiest use of cycle time treats it as a team-level, process-level signal, not an individual performance metric, which removes most of the incentive to game the numbers rather than genuinely improve the underlying flow of work.
Cycle time fits well as a diagnostic for a single team trying to understand and improve its own delivery process over time. Tracked consistently within one team, using one consistent definition, it's a genuinely useful signal for spotting where work gets stuck, whether that's oversized tickets, slow reviews, or a clunky deployment process. It also works well as a leading indicator: a team that sees its cycle time creeping up over several weeks has an early warning that something in its process is degrading, before that shows up as missed deadlines or frustrated stakeholders.
It fits poorly as a comparison tool across teams working on very different kinds of work. A team maintaining a mature, well-tested system with a simple, low-risk deployment process will naturally show a shorter cycle time than a team building new functionality in a complex, poorly tested legacy system, and that difference says very little about which team is working harder or better. Using cycle time as a leaderboard across teams, especially when their contexts differ this much, tends to produce resentment and gamed numbers rather than genuine improvement.
It also misleads when treated as the only metric that matters. A team can achieve an excellent cycle time by aggressively shrinking scope on every ticket, shipping small, safe, low-impact changes constantly, while never actually tackling the harder, more valuable work that takes longer and carries more ambiguity. Cycle time says nothing about whether the work being done is the right work, only about how fast whatever work was chosen moves through the pipeline once started. It needs to sit alongside some sense of outcome or value delivered, not stand in as a complete measure of team effectiveness on its own.
Where it genuinely earns a place is as one input among several, alongside measures like lead time, change failure rate, and some qualitative sense of whether the team is working on things that matter. Used that way, as part of a broader picture rather than the single number that defines success, cycle time helps a team notice process friction early and have a concrete, time-based conversation about where to invest improvement effort next.
Teams that meaningfully improve cycle time usually start by measuring it honestly for a few weeks before changing anything, because acting on assumptions about where time is going, usually wrong assumptions, wastes effort on the wrong fix. It's common for a team to assume coding itself is the slow part, only to find through actual measurement that review wait time or deployment approval is where most of the elapsed time is quietly disappearing.
Once the bottleneck stage is identified, the fix is usually specific to that stage rather than a general call to "move faster." If review is the bottleneck, that might mean setting a team norm that reviews happen within a few hours of being requested, rather than whenever someone gets around to it, or it might mean spreading review responsibility across more people so it doesn't bottleneck on one or two senior engineers. If deployment is the bottleneck, that usually points toward investing in automated testing and a more continuous deployment pipeline, so getting a reviewed change into production doesn't require a person to manually shepherd it through several approval gates.
Breaking work into smaller units is close to a universal improvement lever, because almost every team, regardless of what its specific bottleneck turns out to be, benefits from smaller batches moving through the pipeline. This often requires a cultural shift as much as a process one, since engineers and product managers used to thinking in terms of whole features rather than small, independently shippable slices need practice getting good at that kind of decomposition, and it can feel initially like more overhead to plan work that way.
Finally, teams that sustain improvement in cycle time keep watching the metric after the initial fix, rather than treating one round of improvement as the end of the project. Bottlenecks move. Fixing a slow review process might reveal that deployment is now the next biggest chunk of time, and fixing that might surface a testing gap that was previously hidden behind other, bigger delays. Cycle time improvement tends to be an ongoing practice of finding and clearing the next bottleneck, not a single initiative with a clean finish line.
Cycle time is the elapsed time it takes to complete a piece of work, measured from the moment someone actually starts working on it to the moment it's finished and delivered, excluding any time that work spent waiting in a backlog beforehand.
Cycle time starts when work actually begins, while lead time starts earlier, when the request or ticket first enters the system, meaning lead time includes queue wait time that cycle time deliberately excludes.
Sprint velocity measures the amount of estimated work, usually in story points, a team completes within a fixed time period, while cycle time measures actual elapsed time for individual pieces of work, which makes it a more consistent unit for comparison since story point scales vary between teams.
The most common causes are too much work in progress at once causing context-switching, oversized batches of work that take longer to review and test, slow or delayed code review, and friction in the deployment or release process that adds waiting time after the actual coding is done.
No, using it as an individual performance metric tends to incentivize breaking work into artificially small, gamed tickets rather than genuinely improving the flow of work, and it's best treated as a team-level or process-level signal instead.
Generally yes when achieved honestly through smaller batches and less friction, but a very short cycle time achieved by avoiding harder, more valuable work in favor of trivial changes is not a genuine improvement, so it needs to be read alongside some sense of the value being delivered.
Most teams use their project management or engineering analytics tooling to track timestamps for when work moves into an "in progress" state and when it's marked done or deployed, often broken down further into stages like coding, review, and deployment to see where time is actually spent.
It's risky to compare directly, since teams working on different kinds of systems, some more mature and well-tested, others newer or more complex, will naturally show different cycle times for reasons unrelated to how well either team is actually performing.
Because most modern engineering analytics and project management tools now track and break it down automatically by stage, and because it gives teams an honest, time-based way to spot process friction and improve delivery speed without relying on inconsistent, easily gamed measures like story points.
