The tracker became an authority it was never built to be

Open Confluence on any team that has been running for more than eighteen months.

Find the product spec for the last major feature you shipped. Then find the one before that. Then find the decision log from the architecture review that happened before any of those features got written.

At some point you will find a document dated fourteen months ago titled “v3 – FINAL – USE THIS ONE.” Below it will be “v3 – FINAL FINAL.” Below that, one with no date and no author that contradicts both.

You will not know which one reflects what was actually built. Neither will anyone else.

This isn’t a documentation problem. It’s structural. And it’s costing your team more than hours: it’s costing you product accuracy.

What Jira and Confluence were built for

Jira and Confluence weren’t built badly. I’d argue they were built exactly right, for a coordination problem that was real and hard to solve any other way.

In the early 2000s, building software meant distributed teams across time zones, asynchronous handoffs between people who rarely spoke in real time, and long-running projects where institutional memory had to live somewhere other than in someone’s head. Jira was a tracker for work that moved slowly enough that you could write it down, assign it, and close it later. Confluence was a place to store decisions for an audience who might need them weeks or months after the decision was made.

Those constraints shaped the tools. The tools solved that problem well.

The tools evolved. Their core assumption did not: storing and routing work is treated as sufficient evidence that the work is still valid.

What is in the junkyard

Modern product teams are running AI-assisted development cycles. AI can compress some implementation cycles from weeks into days. The feedback loop can now move faster than the systems recording its decisions.

But the Jira board looks the same as it did in 2018.

Here is a composite of what’s in there right now, on teams running longer than a year:

Tickets from a sprint three months back, never closed, because the feature got deprioritised and nobody closed them. They’re technically “in progress” in a column nobody looks at anymore. Confluence pages documenting a decision that got reversed six weeks later. Nobody touched the page. User stories with acceptance criteria written before the customer interview that changed the requirement. Nobody went back and fixed the ticket. And then the real shape of it: hundreds of items in the backlog, only a fraction of which still reflect current intent. Good luck telling which fraction without opening every single one.

Nobody here is careless. The junkyard is the predictable output of a system that records intent at a single point in time and has no way to flag when that intent expires.

What it costs

The obvious cost is the hours. Grooming a backlog of hundreds of items to find the fraction that’s still real. Re-reading Confluence pages to figure out which version to trust. Writing the same requirement three times, in three different formats (PRD, Confluence page, Jira ticket), that immediately diverge from each other.

The less visible cost is accuracy.

Engineers build to the ticket. If the ticket reflects intent from four months ago and the intent has moved, they will build the wrong thing. Correctly. The code will be clean. The tests will pass. The feature still won’t match what the business needs today.

AI coding tools make this worse. When a ticket is presented as the execution authority, an agent has no reliable basis for rejecting it as stale. It has no way to know the ticket is a relic, no way to ask whether the acceptance criteria still hold, and no reason to notice that last Tuesday’s customer discovery session contradicts a spec written last quarter.

The agent builds what the ticket says. The ticket says something that was true nine months ago.

Call it what it is: an intent-authority problem. The system remembers what was written. It does not reliably establish whether that intent is still valid enough to become code.

The question behind the question

The question teams usually ask about Jira is: how do we keep the backlog clean? The answer is always some version of grooming cadence, ticket hygiene rules, and someone who is supposed to be the keeper of the board.

Those answers treat the symptom. The symptom is a messy board. The disease is that there is no connection between the current state of business intent and the current state of the backlog.

Every Jira ticket is a claim that a piece of work was valid at the moment it was written. Most of them remain claims about moments that have passed.

The real question is not how to clean the junkyard. It is why building software requires one in the first place.

That question does not have a Jira answer.

What replaces backlog hygiene

The answer is not another cleanup ritual. It is to separate storage from authority.

A work item should be executable only when it can show:

• the current product decision that authorises it
• the evidence and assumptions behind that decision
• who owns its validity and when it must be reviewed
• what supersedes or invalidates it when intent changes

When customer evidence or a product decision changes, affected work should be marked for review before a person, or an agent, acts on it. Search is not enough. Version history is not enough. Even approval is not enough if the approved artifact has since been superseded.

Jira can still track the work. Confluence can still explain it. But neither should become the authority merely because an artifact remains visible.

The junkyard is not old work. It is old intent that still retains permission to become code.