Cycle Time

Two people describing the same task would routinely give wildly different durations. The marketer says changing one line of banner copy takes two weeks. The engineer says that's 30 minutes of work. Neither is lying: counted from the day the request came in it really is two weeks, and counted from the moment someone touched it it really is 30 minutes.

Without separating those two, teams fix the wrong thing. The requester calls the team slow, the team tries to build faster, and meanwhile the place the time actually went wasn't the building at all — it was the ten days the card spent in a queue with nobody on it. Adding people does nothing to those ten days.

Cycle time exists to pull the two apart. It measures only the stretch between a card entering the in-progress column on the kanban board and arriving in done. Put it next to the number that starts at the request and the gap between them is the waiting, which turns "which half should we fix" into something you can read off a chart.

Record when a card enters the in-progress column and when it reaches done, measure the span between, and look at recently finished cards as a distribution.

The team has to agree on a single start point first. Whether the clock starts when the card is queued, when someone is assigned, or at the first commit changes the same task's number several times over. Fix the end point the same way, at the moment the work meets the definition of done — a checklist the team agrees on in advance, usually something like reviewed, tested, and running in production.

The calculation has three steps.

1. Collect 30 to 50 recently finished cards. Five is too few to show a distribution, and six months of history describes a team that no longer exists.
2. Count the business days between start and finish for each card. Dropping weekends is what makes a card started on Friday and a card started on Monday come out the same.
3. Report the median and the 85th percentile instead of the mean. The median is the value half the cards finished within; the 85th percentile is the value 85 out of 100 cards finished within.

Averages get abandoned because one or two cards drag the whole number. Ten cards at 1, 1, 2, 2, 3, 3, 4, 7, 12 and 30 days average out to 6.5, but half of them finished within three. No card actually experienced 6.5 days. The median here is 3 and the 85th percentile is 12, and those two describe the team far better.

A narrow spread matters before a short value does. A team at a median of 3 days and an 85th percentile of 5 can tell you how long the next card will take. A team with the same 3-day median and an 85th percentile of 21 can promise nothing. What happens in the second team is that most cards finish in three days and roughly one in six takes three weeks, and there's no way to know in advance which one.

So the number you quote outside the team is the 85th percentile, not the median. Commit to the median and you're late every other time.

Bringing the number down usually isn't about building faster. More than half of cycle time is time nobody spent touching the work, so that's where the reduction comes from. The first move is a work-in-progress (WIP) limit, which caps how many cards can be open at once. Push more cars onto a single-lane road and every car gets slower; open six cards at a time and each one waits behind someone else's turn.

Slicing work into consistent sizes narrows the spread too. One three-week card pushes the 85th percentile up by itself. To see which column eats the time, use a cumulative flow diagram, a graph stacking the number of cards per state over time — the column whose band keeps thickening is the bottleneck, the slowest stretch that sets the pace for everything behind it.

Absolute values can't rank teams. Column definitions and slicing habits differ, so team A's three days and team B's three days aren't the same thing.

"Median cycle time is 3 days but the 85th percentile is 21. We can't promise 3."

Half finish in three days, but the rest are scattered too widely to commit to.

"Nine days of lead time against two days of cycle time — what we need to fix isn't how fast we build."

Seven of those days were queue time, so the intake process is the thing to change.

"This month's number went up because the cards got bigger, not because we got slower."

The metric looks worse, but the cause is work size rather than pace.

At Pagedeck, Theo pulls the numbers off the board every two weeks. Last quarter the median was 3 days and the 85th percentile was 19. Gathering the 19-day cards together showed most of them had stalled in the review-waiting column: two days of building, twelve days of waiting.

When Theo brought that in, Mia suggested lowering the in-progress limit from four to two rather than adding a second reviewer — open fewer at the front and less piles up at the back. Two months later the median was still 3 days and the 85th percentile had come down to 8.

The most common misreading is that shortening cycle time means building faster. It measures time, so it looks like a question of pace. Break the span apart, though, and the hands-on portion is usually under 20 percent; the rest is waiting. A reviewer is holding another task, or the previous card hasn't cleared so the next one can't start. Adding people to that only raises the number of cards open at once and widens the spread further.

Using it to compare individuals or teams is the other one. Time looks like a universal unit, so comparison feels fair, but the measured span and the slicing differ everywhere. Worse, the moment the number goes into evaluation, teams start slicing cards finer and stamping the start later. Six months on the number has fallen from 5 days to 2 and the requester's experience hasn't changed at all. Reading throughput alongside it exposes that: throughput is the number of cards finished in a period, so if cycle time halved and throughput held flat, only the slicing changed.