Putting error budgets into the backlog, not next to it
For two years our SLO dashboard and our sprint board lived in different tabs. The dashboard was red more often than anyone liked, the board was full of features, and every planning meeting ended the same way: reliability work was "important, but not this sprint".
The problem was never that people didn't care. The problem was that the error budget was a chart, and the backlog was a list. Lists win prioritisation fights against charts every single time.
Make the budget a ticket
The change was almost embarrassingly small. At the start of each sprint we create one ticket per service whose error budget burned faster than 1× over the previous four weeks. The ticket contains three numbers and nothing else:
- budget remaining for the 28-day window,
- the burn rate over the last 7 days,
- the top two contributors from the incident log.
That ticket gets estimated and ranked like any other item. If the team decides to defer it, that's fine — but the deferral is now visible on the board, with a name next to it.
A simple policy that people actually follow
| Budget left | What happens in planning |
|---|---|
| > 50% | Business as usual, ticket is informational |
| 20–50% | At least one reliability item enters the sprint |
| < 20% | Feature work for that service pauses until the trend reverses |
A policy that needs a meeting to interpret is not a policy. Three rows in a table is about the limit of what survives contact with a deadline.
What changed
Within a quarter, the number of sprints where reliability work was silently dropped went from "most of them" to almost none. Not because anyone became more disciplined, but because the work was finally sitting in the same place as everything else we promised to do.
Next time: how we size these tickets without turning every estimate into an argument about log retention.
← All posts