What is Cycle Time?
Cycle Time
Cycle time is the time a task takes from when work starts to when it's delivered, counting only active work, not time spent waiting.
Cycle time is the time a task takes to move from when work begins to when it's delivered. On a Kanban board, that's the clock starting the moment a card enters "In Progress" and stopping the moment it reaches "Done". Unlike lead time, cycle time doesn't count how long the task sat in a backlog before anyone picked it up.
Cycle time is an internal efficiency measurement. It tells a team how fast it executes once it commits to a piece of work, separate from how long requests wait to be started. A team that improves its cycle time is getting faster at the work itself, not only clearing a backlog faster.
Cycle time is often confused with lead time, a related but broader metric that starts the clock at the request, not at the start of work. Both matter, and they answer different questions. See Lead Time for the full definition of that metric and how the two combine; this entry focuses on cycle time.
The Cycle Time Formula
Cycle time equals completion date minus start date, where start date means the moment someone begins the work, typically when a card enters an "In Progress" column, not when it was created or requested. That distinction is what separates cycle time from lead time, and it's the most common source of confusion when teams calculate it.
Cycle Time vs Lead Time: A Quick Comparison
Both metrics measure elapsed time, but they start the clock at different points and answer different questions.
| Metric | Clock starts | Measures | Best for |
|---|---|---|---|
| Cycle time | Work begins (In Progress) | Team execution speed once work starts | Improving internal process and estimates |
| Lead time | Request or ticket created | Full client-facing wait, including queue time | Setting client expectations and SLAs |
What Drives Cycle Time Up
Several factors extend cycle time once work has already started.
- Task complexity, a genuinely bigger piece of work takes longer no matter how well it's run
- Context switching, a person split across 3 or 4 active cards finishes each one slower than if focused on one
- Unclear requirements discovered mid-task, which pause active work while someone gets an answer
- Review bottlenecks, where the task sits in progress waiting on one person's feedback
- Blocked dependencies, where a task can't move forward until another task or an external input finishes first
A Worked Example: Measuring Cycle Time on a Design Task
A homepage redesign task moves through two active stages before it's done.
| Stage | Entered | Left | Time in stage |
|---|---|---|---|
| In Progress | Mon 9:00 AM | Wed 11:00 AM | 2 days 2h |
| Review | Wed 11:00 AM | Thu 4:00 PM | 1 day 5h |
| Done | Thu 4:00 PM | - | - |
Average Cycle Time Hides the Real Story
A team's average cycle time might be 3.5 days, which sounds predictable. But averages hide spread. If most tasks finish in 2 days and a smaller share take 9 or 10, the average of 3.5 doesn't describe either group, and it's the 9-day tasks that miss deadlines.
Looking at the 50th percentile, the typical task, alongside the 85th percentile, the slow tail, gives a far better picture than a single average. For a 10-person team, a reasonable target is a 50th percentile cycle time under 3 days and an 85th percentile under 7, tracked separately by task type.
Reducing Cycle Time
Once work has started, a handful of practices keep cycle time short and predictable.
- Keep WIP limits tight enough that nobody juggles more active cards than they can focus on in a day
- Break tasks larger than 2 to 3 days into subtasks, so partial progress is visible and blockers surface earlier
- Set a review SLA, feedback within 4 business hours, so tasks don't stall waiting on one person
- Surface blocked tasks immediately instead of letting them sit quietly inside "In Progress"
Cycle Time in Melororium
Project History timestamps every column change on a card, so cycle time, In Progress to Done, is calculable directly from the record for any task. Work Reports break tracked hours down by task and by stage, which helps separate genuine work time from time a card spent sitting untouched inside "In Progress". Project Alerts flags a card that hasn't changed status in a set number of days, catching a cycle-time problem while there's still time to fix it.
In Melororium
Track cycle time from task history in Melororium
Common mistakes with cycle time
What teams get wrong most often, and what to do instead.
- 1
Starting the clock at task creation instead of work start
Calculating cycle time from when a card was created rather than from when someone began the work. That number is lead time wearing cycle time's name, and it makes the team's execution speed look worse than it is.
- 2
Letting a paused task keep the clock running
Leaving a card in "In Progress" while it's stalled waiting on a client answer or a missing asset. The measured cycle time balloons even though nobody was working on it, and the real bottleneck, the wait, stays invisible.
- 3
Moving cards to "In Progress" before work starts
Dragging a card forward early to make the board look active, or to shorten the measured cycle time. The number improves on paper while the real pattern of work doesn't change at all.
- 4
Comparing cycle time across unlike task types
Putting a 2-hour bug fix and a 2-week feature build in the same cycle-time bucket. The blended number doesn't tell either team anything they can act on.
Frequently asked questions
What's a good cycle time for a design or development task?
It depends heavily on task size, so there's no universal number. For agency-sized tasks, a few hours to a few days of work, a 50th percentile cycle time of 2 to 3 days and an 85th percentile under 7 days is a reasonable target, tracked separately by task type.
Does cycle time include weekends?
Most teams calculate it in calendar days by default, since that's what the timestamps on a board naturally produce. Some switch to business-day cycle time for internal reporting so a task that sits over a weekend doesn't look artificially slow.
Is cycle time the same as velocity?
No. Cycle time measures how long one task takes, start to finish. Velocity measures how much work a team completes over a fixed period, like a sprint. They're related, a faster cycle time usually raises velocity, but they measure different things.
Why does cycle time increase over the life of a project?
Usually because complexity grows, dependencies pile up, or the same people get spread across more concurrent tasks as a project matures. Tracking cycle time by phase, rather than only as a project-wide average, surfaces this before it becomes a deadline problem.
Does Melororium calculate cycle time automatically?
Project History timestamps every status change on a card, which makes cycle time, In Progress to Done, calculable directly from the task record.
