Engineering delivery
Most teams forecast delivery off the average. It's the one number almost guaranteed to misrepresent the system — and every time you quote it and miss, you spend trust you didn't have to. Here's what to quote instead.
Once a team starts measuring delivery — the metrics that show where it actually breaks — the next question from founders is always the same: given all this data, when can we promise something? Almost everyone answers with an average. It's the worst available number for the job.
Managers reach for the average because it collapses a messy reality into one number you can say out loud in a standup. That comfort is exactly the problem.
Take a month of finished work:
9 tasks finished in ~1 day each
1 task dragged on for a month
→ average lead time ≈ 4 days
No task in this system actually takes four days. Most take one; a single straggler drags the mean up. You can drown crossing a river that's four feet deep on average.
The average lead time describes a system you don't have.
The median is the middle task — half finish faster, half slower. Here it's about one day, and that single number tells you most work flows through quickly.
That reframes the complaint. When someone asks “our average is four days, why are we so slow?”, the average is hiding the real shape: ninety percent of the work is fine, a few tasks are stranded. The times I've pulled up a control chart with a team, the gap between mean and median was usually the whole story — most tickets clearing in a day or two, one or two buried for weeks in a review queue nobody was watching. The system isn't slow. A handful of tasks are stuck.
So the most useful read in the whole exercise costs nothing: put the mean and the median side by side.
| What you see | What it means |
|---|---|
| Mean far above median | Wide spread. Work moves unevenly — some tasks fly, others sit in queues, reviews, approvals. The gap is queue depth. |
| Mean ≈ median | Tight spread. Work moves at a consistent pace. The system is stable and predictable. |
The gap itself is the signal. A fat gap means a long tail — blockers, hand-offs, things waiting on a person. Close those and the mean falls back toward the median. You can see it at a glance, without a stopwatch on anyone.
Stakeholders ask one question: when will it be done? And they want one date, not a statistics lecture. Fair — so give them one date. Just stop picking it from the wrong number.
A point estimate off the average is a promise the spread won't let you keep. Quote “about four days,” miss it, and you've spent trust — then you do it again next sprint. A percentile fixes which number you pick from: it's the value some share of tasks finish within. Pull a real distribution — less extreme than the toy above, same shape — and it reads something like:
| Percentile | Lead time |
|---|---|
| P50 (median) | 2 days |
| P85 | 6 days |
| P95 | 11 days |
Now the choice is concrete. Routine work? Commit to the P85 — “by day six.” Something a customer or another team is blocked on, where a miss is expensive? Quote the P95 — “by day eleven.” Same data, different promise — both ones you'll keep.
This isn't hiding the uncertainty — it's the honest version of a date. You're committing to one you'll hit 95 times out of 100 (or 85, if that's the line you picked), rather than a gut estimate the system's spread was always going to break. If anyone wants the confidence level, give it to them; most just want the date.
The percentile isn't what you tell the stakeholder — it's how you pick the date you tell them.
For a task already in flight, forecast the time it has left, conditioned on how long it's already run, against the same distribution. And the first time you give someone a date and then hit it, you stop being the team that's “always late” and become the team that's “predictable” — a reputation worth more than the occasional fast ticket.
Because predictability — not raw speed — is what the business actually buys. Sales commits to customers on your dates, marketing books launches on them, support staffs against them. A team that's reliably done by Friday beats one that's sometimes done Tuesday and sometimes in three weeks, because everyone downstream can plan.
And a tight spread isn't luck. It comes from controlled work in progress: high WIP builds long queues, long queues create the long tail, and the tail is what pushes the mean above the median — so controlling WIP tightens the distribution on its own. None of this needs a new tool; Jira's Control Chart shows mean, median, and percentiles from data you already have.
Most teams forecast off the average and then wonder why the dates keep slipping. The fix isn't estimating harder. It's reading the distribution you already have — the median for the typical case, the gap for the system's health, and a percentile for the date you commit to.
A few slow outliers pull the arithmetic mean up, so the average sits well above what most tasks actually take. It describes a system that doesn't exist — most work is faster, a handful is far slower — so forecasting off it is wrong in both directions.
When the mean sits far above the median you have a wide spread and a queue problem; when they're close, the system is stable.
Pick it from a percentile (p85/p95) of your cycle-time distribution, not a gut average. Externally you still give one flat date — just the one the system says you'll hit.
You commit to the date, not the probability.
Jira's Control Chart and cycle-time scatterplots show mean, median, and percentile bands from data you already have — no manual time-tracking. Most trackers with a flow or analytics module expose the same.