When a Product Backlog Becomes an Archive

A backlog can survive several changes in strategy and still be introduced as the plan.

Nothing in the tool makes that true.

A plan is a set of current choices. An archive is a record of choices that may matter again. The trouble starts when both live in the same list, use the same visual weight, and compete for the same attention.

Jira does not convert indecision into strategy. It only gives it a column.

A List Is Not a Plan

A list can be long. A plan cannot be infinite.

Planning requires exclusion. Something matters now; something else does not. Something has enough evidence to earn attention; something else remains a possibility. When every request is preserved as active work, the system stops communicating those choices.

This is not an argument for a small backlog at any cost. There is no universal item count that separates a healthy backlog from a broken one. Ten items can be incoherent. Five hundred can include useful history.

The useful distinction is not large versus small. It is active versus historical.

What the Scrum Guide Actually Says

The current Scrum Guide defines the Product Backlog as an “emergent, ordered list of what is needed to improve the product.” It is also the single source of work undertaken by the Scrum Team.

Three words do most of the work here.

Emergent means the list changes as the product and its environment become better understood. It is not a museum of every request ever made.

Ordered means the list communicates a sequence of current decisions. The 2020 revision notes deliberately use ordered rather than prioritized, leaving room for context while preserving the need for focus.

Needed ties the list to improving the product—not merely to the fact that someone once opened a ticket.

The guide does not prescribe an expiration date, a maximum size, or an archive policy. Anyone who claims Scrum requires deleting an item after 90 days is adding a rule that is not there.

But the absence of a universal deletion rule does not make indefinite active status meaningful.

Five Signs the Item Is Historical

An old item is not automatically obsolete. A new item is not automatically relevant. Age is only the prompt to inspect the decision.

An item is probably historical when nobody can answer these questions:

1. What current problem does it represent? Not the requested feature. The problem that still exists for a user, operator, customer, or business.
2. What current objective does it support? A real Product Goal, strategy, constraint, or measurable outcome—not a label left over from an earlier plan.
3. Who owns the decision? Someone with authority to renew, reject, or archive it.
4. What recent evidence justifies attention? Usage, incidents, customer conversations, operational risk, search behavior, or another observable signal.
5. What condition would make it rise? A trigger the team could actually observe, rather than “we may need it someday.”

No single answer proves an item should be built. Together, the answers prove that it still belongs in the active decision system.

Without them, the item may deserve preservation. It does not deserve to impersonate a promise.

Age Is a Clue, Not a Verdict

Kanban gives age a precise operational meaning. The current Kanban Guide defines Work Item Age for work that has started but has not finished. It is one of the minimum flow metrics because elapsed time can reveal risk while work is in progress.

That definition should not be stretched. An unstarted backlog item is not official Kanban Work Item Age just because its ticket is old.

Still, the distinction teaches something useful: age becomes meaningful when it is attached to a decision and a state. For started work, age helps inspect flow. For unstarted work, calendar age can trigger a review of relevance—but it cannot make the decision for you.

The oldest item might represent a regulatory obligation that remains real. The newest item might be a stakeholder's passing idea. Dates are evidence. They are not verdicts.

Why Teams Keep Everything Active

Adding an item is easy. Archiving one feels final.

That asymmetry creates false optionality. Keeping every request active appears to preserve choice, but it also preserves the expectation that someone may deliver it. The organization gets the comfort of saying “it is in the backlog” without making a current decision.

The cost is not a universal dollar figure. It is a loss of signal.

Current problems sit beside abandoned plans. Decision owners have to rediscover context. Refinement spends attention on possibilities that nobody renewed. Stakeholders read continued presence as continued intent.

The list grows, but the plan becomes harder to see.

The Backlog-or-Archive Test

Start with the oldest handful of items. Do not delete anything.

For each item, record the five answers: current problem, current objective, decision owner, recent evidence, and activation condition.

Then choose one of three states:

Active

The problem and objective are current. A decision owner exists. Evidence or a clear trigger makes the item's place in the order intelligible.

Archive

The history may be useful, but the item has no current claim on attention. Preserve its text, comments, links, date, and previous decision. Remove it from the active ordering surface.

Reject

The request is contradicted by current strategy, duplicated elsewhere, or known to be harmful. Keep the decision record, including why it was rejected, so the same argument does not restart from zero six months later.

This is a decision protocol, not a framework certification. Adapt the fields to the system you already use.

“But We Might Need It Someday”

Then keep it searchable.

Searchability does not require active status. A library preserves books without placing every book on the librarian's desk.

If new evidence arrives, restore the item with that evidence attached. The restore path is the point: archiving should be reversible, visible, and boring.

What should not be reversible by accident is the promise. An item should return to active work because someone made a current decision, not because an old filter happened to include it.

What to Measure

Run the test as an experiment, not a cleanup performance.

For the next 30 days, track:

• how many archived items are reactivated;
• whether reactivation arrives with new evidence or only a request to restore visibility;
• how much of refinement is spent on active decisions rather than context archaeology;
• whether stakeholders can identify the current top problems more consistently;
• whether rejected items return without their previous decision record being consulted.

Thirty days is a review window for the experiment, not a universal expiration rule.

If many archived items return with strong evidence, the archive criteria were too aggressive. If almost none return, that is useful local evidence—not proof that every organization should copy the same policy.

Preserve the History. Remove the False Promise.

A healthy backlog does not have to forget.

It has to distinguish memory from intent.

Keep the request. Keep the discussion. Keep the reason it once mattered. But if nobody can name the current problem, the decision owner, or the condition that would make it rise, stop presenting it as active work.

Archive the history. Renew only the promises you are willing to keep.

That is how an ordered list becomes a plan again.