Service Level Expectations: A Forecast, Not a Promise
"We'll deliver it by Friday" sounds reassuring and is almost always a guess dressed up as a fact. A service level expectation replaces that guess with something more honest: what your own past data says is likely.
"85% of items finish in 8 days or less."
Historical data
Derived from the actual cycle times of comparable past work.
Probability
Not a guaranteed date — a risk-aware forecast.
Refresh
Re-evaluated as the flow of work changes.
A single average hides variability. Using a percentile instead — 'most items, most of the time' — makes the uncertainty visible instead of quietly discarding it. Different types of work often need their own dataset, since a bug fix and a new integration don't share the same distribution.
Doing the percentile by hand, once
Say the last 20 comparable integration items had these cycle times, in days, sorted smallest to largest: 4, 5, 5, 6, 6, 6, 7, 7, 7, 8, 8, 8, 9, 9, 10, 10, 11, 12, 14, 19.
For the 85th percentile, take 85% of 20 items — that's 17 — and read off the 17th value in the sorted list: 11 days. So the honest sentence is 'this kind of work finishes in 11 days or less 85% of the time.' Saying that also means knowing what you left out: the remaining 3 items (15%) took longer, one of them 19 days. Drop those two slow outliers and report 'our average is 7.7 days' instead, and you've quietly hidden exactly the uncertainty a stakeholder needs to plan around.
This is also the sentence you actually say out loud to a stakeholder who's pushing for a date: 'I can't promise Friday — what I can tell you is that 85% of similar work like this finishes within 11 days, and I'll update you if that changes once we've scoped it.' It sounds less certain than 'Friday.' It's also the version that's still true three weeks from now.
Starting more doesn't finish more
Less WIP → less waiting per item → shorter feedback loops. It feels counterintuitive, but starting more work at once doesn't speed the system up — it grows the queue every item has to wait behind.
An integration team once kept 12 items open at the same time, and average cycle time had crept up to 9 days. They cut their WIP limit to 6 — nothing else changed, same people, same skills. Three weeks later, average cycle time was down to 5 days, and weekly throughput had actually risen from 4 items to 6. Nobody worked faster individually; each item simply spent less time waiting behind eleven others for the same two reviewers.
Focus improves
Less context-switching and fewer competing dependencies at once.
Blockers surface
Instead of starting new work, what's blocking existing work gets solved.
Risk closes earlier
Work finishes sooner, so its underlying assumption gets tested sooner.
Now practice it
A stakeholder under pressure wants a firm date. Build an honest, probability-based service level expectation instead — with AI rubric feedback.
Open the PracticeLab →Frequently asked questions
Isn't a probabilistic statement just a way to dodge commitment?
No — it's a more honest commitment. A fixed date implies certainty you don't have; a probability statement commits to what your data actually supports, and to updating it as reality changes.
Why does lowering WIP make things faster, not slower?
Every item in progress waits on every other item sharing the same people and attention. Fewer items in progress means less waiting per item, which shortens cycle time and gets feedback back faster — the total capacity of the team doesn't need to change.
What if leadership insists on a fixed date anyway?
Give the probabilistic forecast alongside the risk of a fixed date: a hard promise based on incomplete data is a bigger risk to the relationship than an honest range, especially once it's missed.