Cycle Time Scatterplots: Reading Your Team's Real Delivery Range

Introduction

A team reports an average cycle time of six days. Someone asks whether a new request will be done within a week, and the answer seems obviously yes.

Then you look at the actual items. Most finished in two or three days. A handful took twenty-five. Almost none took six. The average is a number that describes no item the team has ever delivered, and the week-long promise it implied is broken roughly a third of the time.

The scatterplot is the chart that makes this visible, and the percentile is the number you should have been quoting instead.

What Is a Cycle Time Scatterplot?

A cycle time scatterplot puts one dot per completed item on a chart: the date it finished along the horizontal axis, and how many days it took up the vertical. Horizontal percentile lines are drawn across it, typically at 50, 85 and 95 percent, showing the cycle time that each proportion of items came in under.

Unlike a bar chart of averages, it shows every item individually, which is the point: the shape of the spread carries more information than any summary of it.

Why the Average Misleads

Cycle time distributions are right-skewed, and strongly so. There is a hard floor at zero, most items cluster near the fast end, and a long tail stretches to the right made up of items that hit something unexpected.

The mean of a right-skewed distribution gets dragged upward by the tail, which produces two opposite errors at once. It overstates the typical item, so the team feels slower than it is. And it understates the risk on any particular item, because the tail extends far past the mean.

Nothing about the average is salvageable here. Percentiles do not have this problem because they are positional: the 85th percentile is the value that 85 percent of items came in under, and the tail cannot drag it.

Reading the Three Lines

The 50th percentile

Half your items finish faster than this, half slower. This is what people mean when they say "how long does a typical item take", and it is almost always well below the average. Useful for internal conversation, useless as a commitment, because a promise you keep half the time is not a promise.

The 85th percentile

The workhorse. Eighty-five percent of items finish within this time. This is the number to quote to anyone asking for a commitment, and the number to use as the line for work item age: an item past the 85th percentile is genuinely abnormal and worth a conversation.

The 95th percentile

The worst realistic case, excluding disasters. Useful when someone needs to know how bad it could get, and useful as a check on the gap: if the 95th is four times the 85th, your process has a failure mode that fires one item in twenty, and finding it is worth more than any general improvement effort.

Turning a Percentile Into a Service Level Expectation

Once you have the 85th percentile you can make a statement that is both specific and defensible: "Eighty-five percent of our work is delivered within eleven days."

That is a service level expectation, and it is a fundamentally different kind of commitment from an estimate. It is a claim about your system's observed behaviour rather than a prediction about one item, which means it is checkable and it improves as you improve. It also survives contact with an item that turns out to be difficult, because it never claimed every item would be fast.

Two rules keep it honest. Recompute it monthly from a rolling window, because a stale SLE is worse than none. And never quote a percentile you have not measured; the whole value here is that the number is evidence rather than aspiration. See deadlines in continuous flow.

Finding the Outlier Cluster

The most valuable use of a scatterplot has nothing to do with the lines. Look at the dots above the 95th percentile and ask what they have in common.

In practice there is almost always a pattern, and it is almost always one of a short list:

• They involve a specific external dependency or third party.
• They are all one type of work: data migrations, anything touching billing, anything needing design input.
• They were all started when the team was at peak WIP.
• They are all items that were never right-sized and should have been split.

This is the difference between "our cycle time is too high", which generates a vague improvement initiative, and "anything touching the billing integration takes four times as long", which generates a specific fix. The scatterplot is one of the few charts that reliably produces the second kind of statement.

Worth noting the inverse too: if there is no pattern and the outliers are genuinely assorted, that is also a finding. It usually means the variability is coming from how much is in flight rather than from the nature of the work.

Where FlowBoard Fits

FlowBoard does not render a scatterplot. It records cycle time per item from status transitions, which is the raw data the chart is built from, and it reports cycle time and lead time trends directly.

To build the scatterplot itself, export completed items with their start and finish dates and plot them. You do not strictly need the chart, though: sorting your last hundred cycle times and taking the value 85 percent of the way down the list gives you the number, and the number is what you act on.

What to Do This Week

List the cycle times of your last fifty completed items, sort them, and read off the 85th value. Compare it to the average you have been quoting. Then start quoting the percentile instead, and use it as the aging line described in aging work in progress.

Next: Monte Carlo forecasting, which extends the same idea from one item to a whole backlog, and the flow metrics guide.