When a Ready Ticket Is No Longer Ready
We spend a lot of time discussing what makes a good ticket: clear acceptance criteria, enough context, useful links, a decent description.
But there is another factor we rarely talk about: age.
A ticket created last week can be surprisingly short and still be perfectly usable. The team remembers the discussion that created it, the problem is still fresh, and a lot of context doesn't need to be written down because everyone already shares it.
Take the exact same ticket and leave it in the backlog for six months.
The text hasn't changed, but its quality probably has.
Maybe the product evolved. Maybe the code around it changed. Maybe priorities shifted. Maybe the person who created it is no longer on the team. Even when none of those things happened, people simply forget the conversations and assumptions that originally surrounded the ticket.
This is something I discuss in Tech Refinement: context decays.
And it creates an interesting situation. A beautifully structured six-month-old ticket can actually be less useful than a three-line ticket created yesterday. One looks better on paper, but the other still has its context attached to it.
That's why I think stale tickets deserve a slightly different treatment during refinement.
When an old ticket comes back to the top of the backlog, the first question shouldn't immediately be: How are we going to implement this?
It should be: Is this still what we want?
And then: Has anything changed since this was written?
Sometimes the answer is no, and you continue normally. Sometimes the ticket needs to be updated. Sometimes it needs another conversation with Product. And occasionally, you realize that the best thing to do is simply close it.
I've seen a team refine a ticket that had been sitting in the backlog for months, only to discover before implementation that priorities had changed and the work wasn't needed anymore. The refinement itself wasn't bad. The mistake was assuming that an old decision was still a current one.
A ticket being “ready” is not a permanent property.
It was ready given the context that existed when it was refined.
The older that context becomes, the more reasonable it is to challenge it again.
You don't need a new process, an expiration date in Jira, or a rule saying that every ticket older than three months must be rewritten.
Just treat age as a signal.
Before spending engineering time figuring out how to build an old ticket, make sure the what and the why are still alive too.
