Somewhere in your company, there is a ticket old enough to have opinions about the company’s rebrand. Its requester has moved teams. The included screenshot shows a product that no longer exists. Someone has labeled it “medium priority,” which is a different way of saying it will outlive us all. Every few weeks, competent, well-meaning people enter a meeting and provide a “no updates” update.
I would like those people to have their afternoon back.
A backlog is useful when it helps a team decide what to do next. The trouble starts when recording a request quietly becomes a promise to fulfill it.
I understand how this happens. A colleague raises a reasonable concern. You can’t address it right now, but you don’t want to lose it, so you put it somewhere responsible. Repeat this across enough people and enough quarters, and you have a second business to operate: the administration of work you aren’t doing.
This second business can become remarkably sophisticated. It has meetings. Reporting. And rules. But what it rarely has is a convincing answer to a fairly basic question: When, exactly, are we expecting to have less to do?
Too many backlogs depend on a future version of the team with fewer obligations, more capacity, and an uninterrupted week of work. That team is going to be incredible. They’ll fix the navigation, consolidate the templates, revisit the onboarding experience, and finally investigate what “improve discoverability” meant in 2024.
Unfortunately, that future team works here too.
They will have launches. They will see team members come and go. Systems will change. Leadership will discover shiny new priorities. The industry will evolve. Logically, we know this. But we build the backlog anyway.
Part of the appeal is that a ticket changes how a problem feels. Before the ticket, something is unresolved. After the ticket, something is tracked. This is a meaningful administrative distinction and, sometimes, absolutely no change in the experience of the person having the problem. The customer still can’t find the answer. The employee still follows the wrong instructions. The confusing interface remains enthusiastically confusing.
But now there’s a link, which is very easy to mistake for progress.
That mistake gets more expensive when the ticket contains a proposed solution nobody has properly questioned. “Create an article” enters the queue. Weeks later, the team debates when to write it, estimates the effort needed to do so, and asks whether it needs localization.
Nobody asks whether a new article is actually the best solution. Perhaps the answer already exists, but customers can’t find it. Perhaps the interface creates the confusion. Perhaps three existing articles disagree. But the request has acquired procedural momentum. Its existence starts doing the work that evidence should have done. By its fourth review, it feels almost rude to ask whether it should ever have existed in the first place.
Then we add priorities. I have nothing against prioritization. I have questions about a system in which eleven things are critical, thirty-seven are high priority, and everything else has been assigned a priority level that translates loosely to “best of luck.”
A priority field gives us an ordering. It doesn’t tell us whether the work deserves to happen, whether the proposed solution makes sense, or what we’re willing to stop doing to accommodate it. Those decisions require judgment. An intake dropdown offers the pleasant sensation of having exercised some.
The same problem appears in capacity conversations. A large queue looks like compelling evidence that a team needs more people. It may be. But first, we should probably find out what’s in it. How much is agreed work? How much is speculation? How much is blocked on a decision? How many requests describe different symptoms of the same problem?
A hundred tickets might represent a hundred necessary changes. They might represent twelve problems, several duplicates, and a collection of solutions nobody has validated. Backlog size alone won’t tell us which.
And even where the work is necessary, the constraint may sit somewhere else. If every change waits on the same approver, a new writer gives you more drafts awaiting approval. You have increased production in the waiting room.
So what should we keep? For a start, the evidence. Keep the customer complaint. Keep the failed search. Keep the record of the employee who couldn’t complete a task. Give people a reliable way to tell you what’s going wrong.
Someone should be able to report a problem without automatically commissioning a six-stage production process. A team should be able to learn from a request without promising to deliver the requester’s preferred solution.
My rule is that the delivery backlog should contain work we actually have capacity to do.
Future possibilities can live in a higher-level plan. Problems we’re still investigating can remain in a record of evidence. Neither needs to enter the delivery queue just to prove we heard someone.
Before a request earns a place there, I look at a few things beyond priority, in no particular order.
Are these separate problems, or different descriptions of the same one?
A request for an article, a training session, and a tooltip might all point to the same confusing workflow. I’d rather investigate that workflow than congratulate us on having three deliverables.
What happens if we leave this alone?
Someone being mildly inconvenienced and someone being unable to complete a critical task are different situations. I want to understand who is affected, what they’re trying to do, and the consequences of getting stuck.
What makes this time-sensitive?
A launch date, an active customer blocker, or a regulatory deadline can create a real cost of waiting. I want to know what happens if we act next week instead of today. “ASAP” tells me someone wants it soon. It doesn’t tell me why.
Is this recurring, or have we heard it once from someone particularly persuasive?
Repeated failed searches, support questions, and task failures tell us something. So does a rare problem with serious consequences. Frequency helps establish the pattern; it doesn’t get to overrule severity.
Will solving this still matter after the next release?
I distinguish the lasting problem from the proposed fix. Customers may always need to understand a concept, even if the screen they use to act on it is about to disappear. That can make the explanation worth investing in and the elaborate screenshot walkthrough worth reconsidering.
How quickly will the underlying product, policy, or partner workflow change?
A useful asset can become an inaccurate one surprisingly fast. I consider how much detail we can responsibly maintain, what should point to an authoritative source, and whether a smaller interim answer would serve people better while things are moving.
What outcome does this help achieve?
Successful onboarding? Fewer preventable support contacts? Safer decisions? Adoption of something customers need? “A stakeholder requested it” explains where the request came from. It doesn’t explain why we should spend the time.
Then comes the capacity check.
Can someone actually own this work in the period we’re planning? Are the reviewers and dependencies available? Have we allowed for launches and the other obligations that will arrive whether or not they have politely submitted an intake form? If the answer is no, it doesn’t become deliverable because we assign it to someone whose plate is already full.
Accepting new work means using available capacity, changing scope, moving other work, or adding capacity. I want us to say which one we’re doing.
And in content, the estimate cannot end at “publish.” Every new asset brings with it an expectation that we will keep it accurate. The backlog should account for the work we’re creating after the ticket closes, too.
I also want another checkpoint before work begins. Is the problem still happening? Has another change already addressed it? Is the proposed approach still useful? Have the dependencies or business goals changed?
Two things can be true at once: a request may have been reasonable when it arrived AND no longer deserve production. We should be allowed to discover that before we produce it.
For work we defer, I want to know what would change the decision. If adoption grows, we’ll revisit it. If this dependency clears, we can proceed. If the problem starts affecting a critical task, we’ll reassess. Those are conditions a team can evaluate. “When things calm down” belongs in a wellness journal.
Sometimes the answer is: “We agree this is happening. We’re still deciding what would help.” Honest. Useful. No imaginary delivery date required.
And some requests need a plain no. A thoughtful no can explain the tradeoff, acknowledge the problem, and leave room for new evidence. People may dislike it, but they can still make decisions with it, whereas an indefinite maybe puts them in a perpetual state of limbo.
Of course, you cannot close a regulatory obligation because the ticket looks dusty. Nor does deleting a known defect repair the product. Required work and unresolved risks need explicit ownership, including when someone decides to defer them. If necessary work exceeds available capacity, that gap needs an explicit decision about resources, scope, timing, or risk. But we should be able to distinguish those obligations from the suggestion to add a downloadable checklist to a page nobody visits. If our process treats both as priorities patiently awaiting their turn, the process needs work.
What I want, ultimately, is a team with enough capacity to notice things. To investigate a pattern before it becomes seven requests. To question whether a new asset is actually the solution. To improve a system without waiting for someone to complain about it.
That time will look suspicious to people who measure a team’s value by the size of its backlog. To those people, I say: give us room to go where the evidence points. The biggest improvements I’ve led came from investigating what the data was telling us, then acting on it. That requires time an endless queue of requests is very good at consuming.
A backlog tells you what’s waiting. It doesn’t tell you what’s worth doing.
A team does not need a permanent surplus of unfinished assignments to justify its existence. Its job is to use its expertise well, including deciding which work would make too little difference to deserve the time. There will always be more things we could do.
We don’t have to give all of them a ticket and a fictional future.