Service Level Expectations: Stop demanding a date

The most common question delivery teams are typically asked is also the most damaging one:


“When will it be done?”


Not because the question is unreasonable, customers are absolutely entitled to ask, but because most organisations answer it in a way that guarantees disappointment. Dates get guessed, confidence gets projected, risks get accepted and uncertainty gets quietly ignored until it turns into high profile failure. Yes, an estimate is better than no estimate but estimates turn into commitments and that only leads to problems.

A better answer requires a change of perspective. It requires recognition that a software delivery organisation operates in a complex (that is un-ordered) environment which means we cannot use deterministic language. We need to switch to a probabilistic approach.

Kanban’s answer to this problem is just that, to use forecasts instead. Unfortunately forecasts are something that management has trouble accepting and often completely misunderstands.

But don’t worry

• it can be explained
• it can be understood
• it has been done
• there’s detail how to do it further below in this article
• and there’s a lot of further reading if you need it.

Kanban’s answer is the Service Level Expectation (SLE).

What an SLE Is (and What It Very Much Is Not)

Let’s get the misconceptions out of the way first.

An SLE is not:
    •    A deadline
    •    A target
    •    A commitment
    •    A service-level agreement
    •    A promise that work will always finish “on time”

An SLE is a forecast.

Specifically, it is a probabilistic statement of how long a single work item is likely to take once started, based on historical data.


For example:


“85% of work items finish in 12 days or less.”

That’s it. No unrealistic promises. Just our best guess, based on data.

If that sounds less comforting than a date, good. Comfort is usually the enemy of predictability.

Why Deterministic Dates Keep Failing

Most software delivery environments still operate as if the future is predictable with enough planning. Your comprehensive 400 lines spreadsheet or detailed Gantt chart will not fix the future. It just isn’t predictable.

Knowledge work is full of:
    •    Unseen complexity
    •    Dependencies you don’t control
    •    Interruptions you didn’t plan
    •    Learning you couldn’t have done earlier

Pretending otherwise doesn’t make delivery more reliable, it just delays the moment you find out you were wrong. And yet , you can still come across many project and programme managers who try to do just that… Anything to avoid having a honest conversation with their stakeholders I guess?!

An SLE acknowledges uncertainty instead of hiding it. It tells the true story.

The Real Purpose of an SLE

The biggest mistake teams make is treating SLEs as a target to “hit”.

The primary purpose of an SLE is not compliance, it is early warning.

An SLE answers two critical questions:
    1.    How long should this reasonably take?
    2.    When should we start worrying?

Without that second question, predictability is impossible.

SLEs Only Matter When Combined with Age

On their own, SLEs are static. They only become useful when paired with Work Item Age.

Here’s the key shift:
    •    Cycle Time tells you what happened
    •    SLE tells you what usually happens
    •    Age tells you what is happening right now

When an item’s age approaches the upper percentiles of your historical data, the probability of missing the SLE increases fast.

That makes SLEs risk alerts, not performance bars.

Percentiles: Where the Signal Actually Is

Let’s say your SLE is set at the 85th percentile.

That means:
    •    When work starts, there’s a 15% chance it will exceed the SLE
    •    That risk is usually acceptable

But as the item ages:
    •    At the 50th percentile, the chance of breach roughly doubles
    •    At the 70th percentile, it approaches 50%
    •    Near the SLE, you’re running out of options

Each percentile crossed is an opportunity to intervene earlier rather than explain later.

If nothing changes as the item ages, you are ignoring the early signals.

Why Leaders Should Care (Even If Teams Don’t)

Here’s an uncomfortable truth: teams often can’t act on SLE risk without leadership support.

Why?
    •    Dependencies sit outside the team
    •    Priority conflicts are managerial decisions
    •    Scope reduction needs authority
    •    Swarming has opportunity cost

SLEs make this visible.
When an item is at risk, the question isn’t “why hasn’t the team finished yet?”
It’s “what decision are we delaying that would reduce this risk?”

That’s a leadership problem, not a delivery one.

Visualising SLE Risk (Not Just the Number)
Many teams actually calculate an SLE, then they write it on the board, but then ignore it.
That’s borderline worse than not having one.

An effective SLE must be:
    •    Visible where work is visible (yes Atlassian, on the board!!)
    •    Interpreted through age
    •    Used as a trigger for conversation

If an item breaches its SLE and nobody noticed until it was finished, the entire effort to calculate it and show it was wasted.
​
Visualise at the right level

There is something else. As  mentioned above, teams often can’t act on SLE risk. This is often because the breach of the SLE is at their level. All other teams look fine so it looks like “your team problem”. But it often is one of the other teams that will make your team breach you SLE. Because there is a dependency. That dependency isn’t visible immediately if you only show SLEs at team levels. So the answer is to visualise SLEs at the level your leadership cares about. This is often a level above the team board - e.g. programme or portfolio level. (More on that later).

Why SLE Breaches Are Not Failures
Another reason SLEs get abused is fear.

Teams worry that breaching an SLE means they’ve “failed”. That fear drives all sorts of counterproductive behaviour:
    •    Padding forecasts
    •    Gaming start dates
    •    Avoiding difficult work
    •    Redefining “done”
This is backwards.

SLE breaches are expected. That’s what probabilistic forecasts mean. Going over the SLE is not a failure, however failing to learn from the experience is.

The problem is having no idea an item was drifting until it was already late.

SLEs Replace False Confidence with Informed Risk

Delivery leaders can’t have certainty. So they need options.

SLEs, combined with age, give you:
    •    Earlier conversations
    •    Fewer surprises
    •    More credible commitments
    •    Better trade-off decisions

And perhaps most importantly, they allow you to say this with honesty:
“Based on what we know, this is how likely it is, and here’s what we can do about it.”
That’s acknowledging uncertainty instead of ignoring it.

If your SLE isn’t making you uncomfortable, it’s probably not very useful

A good SLE will:
    •    Force conversations you’d rather avoid
    •    Expose risk earlier than feels convenient
    •    Challenge optimistic narratives
    •    Reduce the need for escalation later

If your SLE never gets discussed, never gets breached, and never changes behaviour, it’s pointless.

In the next post, we’ll look at Pull-Based WIP Control and why starting work early is one of the most expensive habits delivery organisations refuse to break.