Metric Definition
Start to finish per task
Track from
Task cycle time
Task cycle time is the elapsed time between when work on a task begins and when it is finished. It measures how fast a single piece of work moves through the process once someone picks it up. Tracked across many tasks, it exposes where work flows and where it stalls.
7 min read
What is task cycle time?
Task cycle time is the elapsed time between when work on a task begins and when it is finished. If someone starts a task on Monday morning and marks it done on Wednesday afternoon, its cycle time is roughly two and a half days. It measures the speed of the work itself, counting only the period when the task is actively in progress.
Cycle time is distinct from lead time. Lead time runs from the moment a task is requested, including all the days it waits in a queue before anyone touches it. Cycle time starts the clock only when work begins. Holding the two apart tells you whether your delay is in waiting or in doing.
The value of cycle time is its honesty about flow. A team can feel busy while individual tasks crawl through the process. Averaged across many tasks, cycle time turns that feeling into a number, and watching its spread reveals whether work moves predictably or lurches between fast and stuck.
Cycle time measures active work, not queue time. A task that sits untouched in a backlog for a week and then takes a day to finish has a cycle time of one day, not eight. If you want to capture the waiting, measure lead time alongside it. Conflating the two hides where the real delay lives.
How to calculate task cycle time
Subtract the start timestamp from the completion timestamp for each task. A task started at 9am on the first and finished at 3pm on the third has a cycle time of about two days and six hours. To describe a team rather than a single task, summarise across many: report the median, which resists outliers, alongside a high percentile such as the 85th to capture the slow tail.
The definition of start and finish matters more than the arithmetic. Start should mark genuine active work, not the moment a task was created. Finish should mark the agreed done state, whether that is merged, deployed, or verified. Pick those two events, write them down, and apply them the same way to every task so the numbers stay comparable.
Decide upfront how to treat paused work. If a task is started, blocked for two days, then resumed, you can count the wall-clock span or subtract the blocked period. Either is defensible, but choose one and hold to it, because switching between them makes the trend impossible to read.
- 1
Define the start event
Decide what counts as work beginning, such as a task moving into an in-progress state. Use the same trigger for every task so starts are comparable.
- 2
Define the finish event
Fix what done means, whether merged, deployed, or verified, and apply it consistently. A shifting finish line makes cycle time meaningless.
- 3
Compute the span per task
Subtract start from finish for each completed task. Record it in consistent units, such as business hours or days, across the whole set.
- 4
Summarise with median and percentile
Report the median for the typical task and a high percentile, such as the 85th, for the slow tail. Averages alone hide the outliers that hurt most.
Task cycle time in a metric tree
Cycle time is a single duration, but that duration is the sum of several stages and waits. A metric tree breaks the total back into its parts: the time spent actively working, the time blocked on others, the time waiting in review, and the rework that sends a task backwards. When cycle time grows, the tree shows which of these expanded.
This decomposition matters because each branch has a different owner and a different fix. Long review waits point at reviewer capacity. Long blocked periods point at dependencies and handoffs. Heavy rework points at unclear requirements upstream. A single average cannot tell those apart, so a team optimising the wrong stage can work hard and move nothing.
This is the dashboard-to-decision gap in miniature. A chart that says cycle time rose from two days to three is information, not action. A metric tree that says the rise came entirely from review wait, on a branch owned by a named team, is something you can do next. KPI Tree connects each branch to its accountable owner and pushes an alert when that branch moves, so the slowdown reaches the person who can clear it.
Metric tree insight
When cycle time climbs, resist adding people to active work. Walk the tree first. More often than not the growth sits in blocked or review wait, where the fix is clearing a dependency or freeing reviewer time, not coding faster.
Task cycle time benchmarks
Cycle time benchmarks depend heavily on task size and the kind of work, so treat any range as a rough guide rather than a target. The more useful signal is consistency: a team whose cycle time clusters tightly is more predictable than one with the same median but a wild spread. Watch the gap between your median and your 85th percentile as closely as the median itself.
The ranges below assume small, well-scoped tasks of the kind a team aims to finish within a few days. Larger work should be split before it is measured, because a single multi-week task tells you little about flow.
| Performance tier | Median cycle time | Spread to 85th percentile | What it signals |
|---|---|---|---|
| Elite | Under 1 day | Tight, under 2x median | Small tasks, smooth flow, few blockers |
| Strong | 1 to 3 days | Up to 3x median | Healthy flow with occasional waits |
| Typical | 3 to 7 days | Up to 4x median | Workable but review or dependency drag is visible |
| At risk | Over 7 days | Wide, above 4x median | Oversized tasks or heavy blocking and rework |
How to improve task cycle time
Reducing cycle time is rarely about working faster. It is about removing the waits and the rework that pad the duration. The most reliable gains come from making tasks smaller, clearing dependencies sooner, and shortening the wait before review, because those attack the parts of the tree where time usually hides.
Make tasks smaller
Smaller tasks finish faster and flow more predictably. Splitting oversized work before it starts cuts both the median and the long tail of cycle time.
Shorten review waits
Time waiting for review is often the single biggest slice. Set review service-level expectations and protect reviewer time so tasks do not sit idle.
Clear dependencies early
Sequence work so blocking tasks and approvals resolve before the dependent task starts. Removing the block beats waiting it out mid-flight.
Cut rework at the source
Rework loops come from unclear requirements and late defects. A short discovery step and earlier checks stop tasks bouncing backwards.
Common mistakes when tracking task cycle time
- 1
Reporting the mean alone
A single slow task drags the average up and hides the typical case. Use the median for the central figure and a high percentile for the tail.
- 2
Confusing cycle time with lead time
Counting queue time inside cycle time blends waiting with doing. Keep the start at active work, and measure lead time separately if you need the wait.
- 3
Moving the finish line
If done means merged one week and verified the next, the trend is noise. Fix the definition of finished and apply it to every task.
- 4
Comparing across task sizes
A two-hour fix and a two-week build do not belong in the same average. Split or band by size before comparing cycle times.
Related metrics
Cycle time
Process speed
Operations Metrics
Metric Definition
Cycle Time = Process End Time − Process Start Time
Cycle time measures the total elapsed time from the start to the end of a process. It is a fundamental operations metric used in manufacturing, software development, service delivery, and any context where the speed of a process directly affects throughput, cost, and customer satisfaction.
Sprint velocity
Agile planning metric
Operations MetricsMetric Definition
Sprint Velocity = Sum of Story Points Completed in a Sprint
Sprint velocity measures the amount of work a team completes during a sprint, typically expressed in story points, ideal days, or another unit of estimation. It is a planning tool that helps agile teams forecast how much work they can commit to in future sprints based on their historical completion rate. Velocity is one of the most widely used and most frequently misunderstood metrics in agile software development.
Deployment frequency
DORA metric
Operations Metrics
Metric Definition
Deployment Frequency = Number of Production Deployments / Time Period
Deployment frequency measures how often an organisation successfully releases code to production. It is one of the four DORA (DevOps Research and Assessment) metrics that predict software delivery performance and organisational outcomes. Teams that deploy more frequently deliver value to users faster, reduce the risk of each individual release, and create tighter feedback loops between development and production.
Why did my metric change? A diagnostic framework
Metric Definition
When task cycle time creeps up or drops, this diagnostic framework helps you trace which stage or driver moved it.
Metric trees for operations teams
Metric Definition
Task cycle time sits at the heart of operations performance, and this guide shows how operations teams structure it within a wider metric tree.
See where task cycle time really goes
KPI Tree decomposes task cycle time into active work, blocked time, review wait, and rework, then assigns RACI ownership to each branch. When the slow stage moves, a push alert reaches the accountable owner, and the verified impact loop confirms whether the change actually pulled cycle time down.
