Your team has more user stories than you can ever deliver. The backlog becomes a dumping ground. Difficult to prioritise. Easy to ignore.
So how do you actually know if yours is healthy?
I've been playing with the idea of backlog freshness.
Backlog freshness is the percentage of the backlog that has been created recently.
My team's backlog, for example, is only 7% fresh. There are 84 user stories in it. Only 6 were created in the last 45 days. The maths: 6 / 84 = 0.07 - that's 7% fresh.
Sound familiar? The bulk of that backlog was written by a previous generation of Product Managers and engineers. Priorities have changed. Many tickets are outdated. And everyone ignores the rest.
That means you have an illusion of having lots of work to do. In reality, no one knows how much of it is actually necessary.
So you have two options to make a backlog fresh again:
delay creating stories until they're needed (one to two sprints before, for example)
fearlessly prune your backlog - delete anything not clearly important, and anything unlikely to go into upcoming sprints
(I hear the hoarders out there screaming in despair. For you, the better option might be to hide things elsewhere rather than delete them. As long as they're out of sight from the team, that's fine.)
A fresh backlog removes that overhead. The team stops reconciling last quarter's priorities with this quarter's reality every time they open the board. They focus on the highest, clearest priority - because everything in the backlog is actually worth doing. No archaeology. No debate about what's still relevant.
Start there. Calculate your freshness number - it takes five minutes. Then prune fearlessly.
Is 100% the right target? I'm not sure it is. But I'd bet yours is lower than you'd like to admit.
I'm curious to hear your number.
Filipe Albero Pomar is an engineering manager and speaker based in London. He writes about AI adoption, engineering leadership, and software delivery. Find him at alpomar.dev.
TechLeadConf 2026 · GenAI London 2026
Top comments (0)