LOBUS.WORKS
← All insights
Flow & Measurement

The Promise You Can Actually Keep

1 May 2026·7 min

Your stakeholder asks when the feature will be done. You run a planning meeting, take the average estimate, add a buffer, and give them a date. Two weeks later, you are explaining why the date was wrong.

The explanation usually involves factors that were foreseeable: a dependency that ran long, a review that took more time than expected, a testing cycle that found something. These were not surprises. They were the normal variation of software delivery. The problem was not the execution — it was the commitment. It was made without checking whether the system has historically been able to deliver that quickly.

Where commitments come from now

Most delivery promises originate in planning meetings. A stakeholder asks a question, the team estimates, someone adds a buffer, a date emerges. The date reflects what the room agreed to, calibrated by intuition about past performance and filtered through the social pressure to say something acceptable.

This is not estimation. It is negotiation. The output is a date that satisfies the people in the room, not a statement grounded in what the system has actually done. The two are rarely the same.

The two sources of a promise

A delivery commitment can come from one of two places: what you hope will happen, or what your system has actually done.

The first is a wish expressed with confidence. It uses planning language and precise-sounding dates to describe an optimistic outcome. It is the most common kind of commitment made in software delivery, and it is wrong at roughly the rate that optimism fails to account for real system behaviour.

The second is a statement grounded in evidence. It describes what the system has historically produced for work of this type, expressed in terms of probability. It is less comfortable because it shows uncertainty — but it is more trustworthy because the uncertainty is real.

The SLE: a different kind of promise

A Service Level Expectation is a percentile-based commitment derived from historical cycle time data.

Instead of "this feature will be done by the 15th," you say: "eighty-five percent of items like this one complete within twelve days." That statement comes from your system's actual history. It can be tested — you can check whether the last twenty similar items actually met that standard. It can be tracked — you can tell whether compliance is holding or drifting. When it starts to slip, the slip is visible early enough to do something about it.

Insight

An SLE is a promise derived from evidence. A planning estimate is a promise derived from optimism. Only one of them gets more trustworthy as you gather more data.

This is a fundamentally different kind of commitment. Not because the words are more sophisticated, but because the source is different. It comes from what happened, not what was hoped for.

Why P85, not P50

The 50th percentile — the median — describes typical performance. Half of items finish faster, half slower. If you use P50 as your commitment point, you will be wrong roughly half the time by definition. That is not a commitment. It is a coin flip with a date attached.

The 85th percentile describes what you can defensibly commit to without over-promising. When you say "P85 is twelve days" and use that as your service target, you are right 85 percent of the time, based on your own system's history. The remaining 15 percent are items worth investigating — not as failures, but as signals that something unusual is happening.

P85 is not a guarantee. It is an honest probability, grounded in evidence, that most stakeholders can work with far more effectively than a date that was invented in a meeting.

The SLE is not an SLA

A Service Level Agreement is a contractual obligation, typically imposed from outside, with defined penalties for breach. It belongs in a legal document.

A Service Level Expectation is an internal delivery target you derive from your own data, for your own purposes: triaging in-flight work, communicating realistic expectations to stakeholders, and detecting early when system performance has started to drift. It belongs in the conversation you have every week about what is actually happening.

The distinction matters because SLEs are tools for improvement, not instruments of judgement. When your SLE compliance drops, that is a diagnostic signal — either the target is out of step with current system behaviour, or something in the system has changed. Both are worth examining. Neither is worth punishing.

What the conversation sounds like

The difference in language is significant because the difference in framing is significant.

"This should be done by the 15th" is a statement made under social pressure. When it is wrong, the conversation that follows is about why the team failed to meet its commitment. Blame is the default frame.

"Eighty-five percent of items like this complete within twelve days, and this one is currently at day eight" is a status report. It tells the stakeholder where the item stands relative to the system's normal distribution. When it exceeds the target, the conversation is about probability, risk, and what if anything to do differently. Decisions are the default frame.

One of these conversations produces trust over time. The other erodes it, slowly, each time another date slips.

Tracking compliance

Once you have an SLE, track whether you are meeting it. Count the items that completed within your target and divide by total completions. If compliance holds above 80 percent consistently, the target is calibrated well. If it drops below 70 percent for three or more consecutive periods, either the target is wrong or the system has changed.

A commitment becomes trustworthy the moment it comes from evidence rather than from the pressure to say something acceptable in a planning meeting.

The SLE creates the visibility. Compliance tracking creates the early warning. Together they give you something that a planning estimate never could: a delivery promise that improves as the system improves, and signals deterioration before it becomes a crisis.

What percentage of your last twenty deliveries finished within the timeframe you committed to? If you cannot answer that question in under a minute, you do not have a service level. You have a series of hopes, each dressed up as a plan.