How do you decide which open defects ship as known issues rather than block a release?

## Deferral is the one lifecycle decision that ships Every other terminal state settles a report internally. Deferral pushes a known defect into users' hands deliberately, so it is the transition that deserves the most structure. The failure mode is never a single reckless decision — it is drift: a queue that fills because nobody had time, then gets summarised as "known issues" in the release notes without anyone having decided anything. ## Who owns the call The decision belongs to the person accountable for the release — typically the release or product owner. Testing's job is to state the risk, not to grant or withhold permission; engineering's job is to state cost and blast radius; the owner chooses. Two anti-patterns are worth naming in an interview: - **Test as gatekeeper.** When testing has the veto, engineering argues the risk down rather than describing it, and the conversation becomes political. - **Assignee as decider.** The person who would otherwise have to fix it tonight is the worst-placed person to judge whether it can wait. Practically: a standing deferral review, a small quorum, and a default of *no* — a defect ships as a known issue only when someone said so, on the record. ## What makes a defect a legitimate known issue The useful axis is not how rare or how ugly it is, but **how the harm behaves after release**: - **Bounded and reversible** — a wrong label, a misaligned layout, a slow screen with a workaround. The damage stops when the fix ships. Good candidates. - **Detectable** — the user can tell something is wrong and can react. A visibly failed submission is far safer to defer than a silently mis-saved one. - **Accruing** — wrong values written to stored records, lost work, anything that corrupts state or misinforms a downstream decision. Deferring these means also owning the cleanup for every day they ship, and that cost is usually far larger than the fix. A tax-filing wizard that writes a wrong filing date onto submitted returns is the archetype: rare, cosmetic-looking on screen, and unbounded once returns are filed. - **Trust-shaped** — anything that touches money, identity, permissions, or a legal or regulatory obligation. These are usually not deferrable at all, and the deferral discussion should not consume the room's time pretending otherwise. Severity and urgency ratings are inputs to this conversation, not the answer to it — two defects with identical ratings can differ completely on whether the harm keeps accruing. ## The known-issue entry as an artefact A deferral is only real if it produces something a stranger can act on. A defensible entry carries: 1. the record identifier, so it stays linked to the evidence; 2. the symptom in **user language**, not internal terms — support reads this, not the code; 3. who is affected and roughly how often, honestly stated; 4. the workaround, or an explicit statement that there is none and the risk was accepted; 5. a named owner; 6. a revisit point — a date or a release, not "when we get to it". Missing the workaround is the most expensive omission, because the support cost of a defect with no advice is many times the same defect with a paragraph of advice. ## Publish it outward The list belongs where support agents, documentation and, where appropriate, users can see it — not only inside the process where the team already knows. Deferral is a decision to accept harm; the mitigation is warning the people who will absorb it. A team that defers 23 defects and tells nobody has not accepted risk, it has transferred it silently. ## Stopping the graveyard Deferred defects rot in a predictable way: the list grows, nobody rereads it, and after two releases it is treated as an archive. Countermeasures that work: - **Expiry by default.** Every entry has a revisit date; on that date it is re-triaged and either fixed, deliberately re-deferred with a new date, or closed with a stated reason such as the behaviour being accepted as designed. Silence does not renew a deferral. - **A cap you actually feel.** Some teams fix the list at a size and require removing one before adding another. Crude, but it forces the conversation the queue otherwise avoids. - **Re-triage on change of context.** A deferral is a judgment about a moment. When the feature's usage jumps, a regulatory deadline lands, or a related area changes, the old judgment is stale and the entry deserves a fresh look. - **Ageing as an input.** A defect deferred three releases running either matters and should be scheduled, or does not and should be closed honestly. Perpetual deferral is a decision nobody made. ## What an interviewer is listening for Not a policy recital. They want to hear that you distinguish bounded harm from accruing harm, that you put the decision with the accountable owner rather than with whoever pushes hardest, that you insist on a workaround or a written accepted risk, and that you have a mechanism — not an intention — that stops the list from silently becoming permanent.