01 Overview
Bug reports and feature requests often arrive through the same channel, and reporters do not always know which label fits. A tester or engineer reading the queue sees a title like "Export button missing" or "Cannot filter by date" and must decide whether the product is broken or merely incomplete. That decision shapes everything downstream: who owns the work, how it is prioritized, and whether the reporter receives a fix or a roadmap conversation. Treating every request as a defect inflates the bug count and distorts quality metrics, while dismissing every ambiguous report as a feature request erodes trust with the people who took time to write it.
The craft here is not about catching people in a mistake. It is about reading the claim beneath the words, separating observed behavior from desired behavior, and routing the report to the place where it can be evaluated honestly. A report that says "the app should remember my last filter" may be a defect if the product previously did so, or an enhancement if it never did. The same sentence can describe a regression, a gap, or a new idea, and only evidence and context can tell them apart.
This article focuses on the triage decision itself: how to interpret the claim, how severity and priority diverge, how to write steps that expose the truth, how to run a queue that handles mixed reports, and what to do when a closed report returns. The goal is a repeatable habit that keeps defect tracking meaningful without turning every missing preference into a crisis.
02 What the report is actually claiming
Every report contains two layers: the observed behavior and the expected behavior. The observed layer is what the reporter saw, and it is usually reliable enough to investigate. The expected layer is where disguised feature requests hide, because the reporter's expectation may come from a competitor, a previous version, a personal workflow, or an assumption about how the product ought to work. When the expected behavior was never promised or documented, the report is describing a gap rather than a break. When the expected behavior was promised and no longer happens, the report is a genuine defect.
Read the report for verbs that reveal intent. Phrases like "does not work" or "is broken" suggest the reporter believes something failed. Phrases like "should also" or "would be better if" suggest a desired improvement. Neither phrasing is conclusive, because people often call missing features broken when they are frustrated. The stronger signal is whether the reporter can point to a specification, a prior release, a help article, or a reasonable user expectation that the current behavior violates. If they cannot, the claim is likely an enhancement wearing a bug costume.
A useful habit is to restate the report in two sentences: one describing what happens, one describing what the reporter wants instead. If the second sentence introduces a capability that does not exist anywhere in the product, you are probably looking at a feature request. If the second sentence describes behavior that used to exist or was explicitly designed, you are probably looking at a defect. This restatement also gives you language for the triage discussion, so the decision is about the claim rather than the person who filed it.
03 Severity versus priority
Severity measures how much damage the reported behavior causes. Priority measures when the team intends to address it. These are independent axes, and confusing them is the most common source of triage friction. A missing export option may have low severity because nothing breaks and no data is lost, yet high priority because a major customer depends on it for a contractual workflow. A cosmetic misalignment may have low severity and low priority, while a rare data corruption bug may have high severity but low priority if it only occurs in a deprecated path that is scheduled for removal.
For reports that might be feature requests, severity is often the wrong lens entirely. If the product never promised the behavior, there is no defect severity to assign, because nothing is broken. The question becomes whether the missing capability matters enough to schedule. That is a priority and roadmap conversation, not a severity judgment. Assigning a severity to a non-defect creates false urgency and pollutes metrics that teams use to judge release readiness.
Priority, by contrast, applies to both defects and enhancements. A team can decide that a low-severity defect is worth fixing now because it affects a key workflow, and it can decide that a high-severity defect in an unused feature can wait. When a report is reclassified from bug to feature request, the severity field should be cleared or marked not applicable, and the priority discussion should happen with the people who own the roadmap. Keeping the axes separate keeps the queue honest and prevents disguised requests from borrowing the urgency of a defect.
04 Writing steps someone else can follow
Reproduction steps are the backbone of any triage decision, because they turn a claim into evidence. For a suspected feature request, the steps often reveal that the product behaves exactly as designed. The shortest reliable sequence is best: start from a known state, list the actions in order, and describe what appears at each step. Avoid mixing in what the reporter wanted to happen; keep the steps observational. If the reporter cannot provide steps, the report is not ready for triage, and the first action is to ask for them rather than to guess.
Good steps name the starting conditions, such as the account type, the data set, the browser or device, and any prior actions that matter. They use plain verbs and avoid internal jargon. They include the exact input values when those values affect the outcome. They end with the observed result, stated without judgment. A reader should be able to follow the steps and see the same thing, which is what makes the report reproducible and the triage defensible.
When the steps show that the product is working as designed, the report is likely an enhancement. When the steps show a crash, an error, a wrong value, or a broken workflow, the report is likely a defect. When the steps are ambiguous or incomplete, the correct triage outcome is a request for more information, not a guess. Writing steps that someone else can follow is a service to the whole team, because it shortens the path from report to decision and reduces the back-and-forth that delays real fixes.
05 Running the triage queue
A triage queue works best when it has a consistent rhythm and a clear owner. The owner reads each new report, checks whether it has enough information, and makes a routing decision: confirm as a defect, reclassify as a feature request or enhancement, request more information, or close as not a bug. The decision should be recorded with a short reason, because future readers will need to understand why a report was routed a certain way. A queue without reasons becomes a graveyard of ambiguous tickets that nobody trusts.
Group similar reports during review. If several people describe the same missing capability, that is a signal about demand, not necessarily a defect. If several people describe the same broken behavior, that is a signal about impact. Look for reports that contradict each other, because one may be a defect and the other a feature request using similar words. When a report is reclassified, communicate the change to the reporter in plain language, explaining what was observed and what will happen next. Reclassification is not rejection; it is routing to the right process.
Keep the queue moving by setting a target for how long a report waits before its first decision. A report that sits unresolved for days invites duplicate submissions and erodes confidence. If the queue is large, sort by age and by whether the report blocks other work. The goal is not to close everything quickly but to make a defensible decision on every item, so that defects reach engineers and enhancements reach the people who plan the roadmap.
06 When a defect comes back
A defect that returns after being closed is a special kind of triage problem. It may be a genuine regression, a fix that did not cover all paths, or a report that was misclassified the first time. Start by comparing the new report to the original. If the original was closed as a feature request and the new report describes the same missing capability, the reclassification was probably correct and the new report should follow the same path. If the original was confirmed as a defect and the behavior reappears, treat it as a regression and link the reports so the history is visible.
Reopened defects deserve a fresh look at severity and priority, because the context may have changed. A bug that was low severity in an old release may be high severity now if the affected workflow has become critical. A bug that was fixed once may need a stronger test or a guard to prevent the same regression. The triage decision should include whether to add a regression test, update the reproduction steps, or adjust the affected area so future reports route correctly.
When a defect comes back, avoid blaming the original reporter or the original fixer. The useful question is what the new evidence changes about the claim. If the new report is actually a different feature request, say so clearly and route it accordingly. If it is the same defect, confirm it, set priority with the current context, and close the loop with the reporter. A returning defect is not a failure of triage; it is new information that the queue should absorb and act on.
07 Frequently asked questions
How do I tell a feature request from a bug when the reporter insists it is a bug? Focus on the expected behavior. If the product never promised the behavior and no prior version provided it, the report is describing a gap, which is an enhancement. If the behavior was promised, documented, or previously present, it is a defect. The reporter's label matters less than the evidence, and your job is to explain the distinction without dismissing their concern.
Should a reclassified feature request keep its severity? No. Severity describes damage from a defect, and a missing capability is not damage. Clear the severity or mark it not applicable, then discuss priority with the people who own the roadmap. Keeping a severity on a non-defect creates false urgency and distorts quality metrics.
What if the report has no reproduction steps? Ask for them before making a triage decision. Without steps, you cannot confirm a defect or evaluate a feature request, and guessing wastes engineering time. A short, polite request for the starting state, the actions, and the observed result is usually enough.
How long should a report wait before triage? Set a target that fits your team's rhythm, and treat it as a service level for decisions, not for fixes. The important thing is that every report receives a recorded decision with a reason, so reporters and engineers know where it stands and what happens next.