Six months ago, your biggest customer threatened to churn. They needed a reporting dashboard. It was urgent. The CEO got involved. A ticket was created. Priority: critical.
Then the customer renewed anyway. The CEO moved on to the next fire. The ticket stayed.
Three sprints later, a developer picks it up. Spends two weeks building it. Ships it. Nobody uses it. The customer who asked for it doesn’t even remember asking.
Giphy
This happens constantly
It’s not always this dramatic. Sometimes it’s a feature request from a user interview that felt important in February but irrelevant by August. Sometimes it’s a competitive response to something a rival shipped. By the time you build it, the market has moved.
The pattern is the same. The decision to build something was made in a moment. The building happened later. The moment had passed.
The cost is invisible
Nobody tracks “features built past their expiration date.” There’s no JIRA field for that. So it doesn’t show up in any report.
But the cost is real. Engineering time. Opportunity cost. Maintenance burden on something nobody wanted. Code complexity that compounds forever.
And then there’s the morale hit. Nothing drains a team faster than shipping something and hearing silence. No adoption. No feedback. Just the quiet realization that the last two weeks didn’t matter.
Why the system doesn’t catch this
Your tools track whether work is done. They don’t track whether work is still worth doing. A ticket that was created six months ago looks the same as one created yesterday. Same fields. Same format. No expiration date.
The staleness is invisible until you ship and nobody cares.
How to spot it before you build
Before any ticket enters a sprint, ask one question: is the person who requested this still waiting for it?
Not “is this still in the backlog.” Not “does the priority field say high.” Is the actual human who wanted this still expecting it?
If you can’t answer that in 30 seconds, the decision has decayed. Don’t build it. Validate it again or kill it.
Tom