Your product backlog holds 340 items and most have not been touched in months. What do you do?
answer
- A long list is a cost, not an asset
- Measure age since creation
- Inflow against outflow of any kind
- Delete rather than archive
- Fix intake or it returns
basics
~20 sA backlog that size is a liability rather than an asset, because it hides the few items that matter. Measure how long items have waited since creation, delete what nobody will ever pull, and treat refinement as continuous work rather than a meeting.
solid answer
~50 sTreat the size as a symptom and measure before touching anything. The diagnostic numbers are cheap: how long items have waited since they were created, how many arrive per window against how many leave by any route, and the age of the items the team actually starts. If nothing older than a quarter has been pulled in a year, the tail is decoration and you can say so with evidence rather than opinion. Then **delete rather than archive** — a second list rots the same way — and publish the age rule before applying it, so removal reads as maintenance and not as someone's item being thrown away. Finally fix intake, because the rot starts at the door, and keep refinement continuous and confined to the top: detail written for an item forty places down decays before anyone uses it.
go deeper
Know that a backlog can grow past any chance of being finished, and that items go stale because the context around them changes. Being able to say a long list has a cost, rather than treating length as a sign of ambition, is the point at this level.
Explain the mechanics: inflow against outflow, age since creation, and why detail written far down the list decays before use. Be ready to describe how you would take those measurements without building anything elaborate.
An interviewer expects a decision, not a diagnosis. Measure, then delete by a published rule, then close the intake — and be able to defend removing hundreds of items to the people who wrote them.
Own the organisational side: the backlog is where a company's unsaid noes accumulate, and the real fix is making refusal explicit and attributable. Be ready to argue for a size cap and to say what it costs you politically.
## What rot means for a list of intentions A **product backlog** is a list of things somebody once wanted. Nothing in it is a commitment, and nothing in it decays visibly — which is precisely why it rots. An item written eleven months ago looks identical to one written yesterday: same font, same size, same apparent claim on the team's attention. What has changed is invisible. The person who wanted it moved on, the product went a different way, the constraint that made it necessary disappeared, or somebody else has since written the same wish in different words. Rot has one mechanical cause: **inflow exceeds outflow, and outflow has been defined as completion only.** Every stakeholder conversation that ends "let's add it to the backlog" adds an item — a polite way of saying no that sounds like a yes. Almost nothing leaves except by being built. With 340 items and an eleven-person team, arithmetic alone says most of that list will never be pulled. ## The list is not free to keep The usual defence is that a long list costs nothing, because unread items consume no delivery capacity. They consume things that are scarcer: - **Attention.** Every ordering decision is taken against a longer list, and every search returns more near-matches to read past. - **Trust.** Stakeholders who watch their item sit for a year stop believing the list means anything and start routing work around it. - **Signal.** Rot buries the few items that matter; three genuinely urgent items are indistinguishable from 337 that nobody will ever do. - **Honesty about capacity.** A list that would take eleven years to finish is not a plan, and presenting it as one misleads everybody who reads it. - **Consistency.** Nobody reads 340 items before writing the 341st, so near-duplicates accumulate and eventually contradict each other. ## Measure it rather than argue about it Health is a measurement question, and the measurements are cheap to take: | Signal | Healthy | Rotting | | --- | --- | --- | | Age of items since creation | a short tail beyond six months | most of the list predates the last change of direction | | Items added per window against items removed | roughly balanced | inflow several times outflow | | Age of the items actually started | mixed; old items do get pulled | almost everything started was written recently | | Detail per item | rich near the top, coarse further down | uniformly vague, or uniformly detailed | | Near-duplicates | rare | several phrasings of the same wish | The most diagnostic of these is **the age of the items that actually get started**. If the team has not pulled anything older than a quarter in the past year, then everything older than a quarter is decoration, and you can say so with evidence instead of instinct. Keep this measurement carefully separate from how long *started* work has been sitting unfinished. That is a flow measure about work already in progress, with a different remedy; the question here is how long an item waited before anyone touched it at all. ## Fixing it, and keeping it fixed 1. **Delete, do not archive.** Set a stated age at which an untouched item is removed, and remove it. Archiving into a second list simply produces a second rotting list with the same attention cost. A genuine need comes back, and rewriting it in current language is cheaper than having carried it all year. 2. **Cap the size.** A list bounded to roughly what the team could plausibly do in two or three quarters forces the ordering conversation to happen at intake, while the requester is still in the room. 3. **Refine continuously, near the top only.** Refinement is an activity, not a slot in the calendar: small, frequent, and applied to what is about to be pulled. Detail written for an item forty places down decays before it is ever used. 4. **Fix intake or the rot returns.** The rot starts at the door, and "no, and here is why" is a sentence a backlog cannot say on your behalf. 5. **Publish the deletion rule first.** Deleting silently destroys trust; deleting by a rule everyone knew in advance builds it. An eleven-person team building a beekeeping-records product hit exactly this against a regulator's audit date. The list held 340 items, 212 of them predating the last change of product direction, and the three items the audit genuinely required were buried among them. Applying an eighteen-month age rule took one afternoon, removed 244 items, left 96, and made the audit work visible for the first time. Nothing of value was lost, because the value had evaporated long before; only the entries remained. ## What an interviewer is listening for A weak answer proposes a tidy-up session and stops. A strong one measures first, names deletion explicitly as the instrument, distinguishes the age of waiting items from the age of work already started, and closes the intake so the situation does not recur in six months. The senior signal is a willingness to be the person who removes 244 items and defends the decision with numbers.
- A stakeholder objects that deleting items destroys information the team may need. How do you answer?The information was already lost — an item nobody has read in a year is not knowledge, it is a string. Retrieving and re-understanding it later costs more than rewriting the need in today's language, and a real need reliably comes back. If the organisation needs a record for audit reasons, keep one outside the working list. What must not survive is the pretence that an unread entry is a plan.
- What intake rule stops the rot recurring three months later?Make the answer at the door a real one: accept, decline with a reason, or accept against something you are removing. A size cap does this automatically, because adding an item forces a choice about which item leaves. The rule matters less than someone owning it publicly, since rot returns the moment 'add it to the backlog' becomes an acceptable end to every conversation.
- How would you tell backlog rot apart from a genuinely large but healthy list?Look at what gets started, not at the total. A healthy large list still pulls old items, has inflow and outflow in rough balance, and shows detail concentrated near the top. A rotting list of the same size starts only recently written items, grows faster than it shrinks, and is uniformly vague. The count alone tells you nothing about either.
A neglected backlog behaves like a shared fridge: things go in, almost nothing is thrown out, and the smell arrives long before anyone opens the door.
saying these in an interview costs you the question
- Treats a large backlog as evidence of healthy demand
- Archives items into a second list that rots identically
- Refines every item to the same level of detail
- Describes refinement as a meeting held once per window
- Judges backlog health by item count alone
- Deletes items silently without publishing the rule