01 Overview
A backlog breaks in a quiet, specific way. It does not collapse under the weight of too many bugs; it collapses when the fields that describe those bugs stop meaning anything. Severity and priority are the two fields most often conflated, and the conflation is rarely dramatic. Someone marks a cosmetic glitch as critical because it is on the login screen, someone else marks a data-corrupting edge case as low because it only happens to a handful of users, and within a few sprints nobody trusts the labels at all.
The damage compounds. Engineers learn to ignore the severity column and read the whole thread before deciding whether a report matters. Product managers learn to ignore priority and re-rank everything in their own spreadsheets. Testers, seeing their careful assessments overwritten, stop writing them carefully. The backlog still holds the same number of reports, but it no longer holds information; it holds text.
This article is about restoring the distinction as a matter of craft. Severity describes the defect. Priority describes the decision. They are produced by different people, at different moments, for different reasons, and the health of a triage process depends on keeping them apart even when they happen to agree. The goal is not a perfect taxonomy. The goal is a backlog where a reader can trust two columns enough to act on them without re-reading everything.
02 What the report is actually claiming
Every defect report is a claim about the world, and most of the confusion in triage comes from reports that make several claims at once without separating them. A report says something happened, that it happened under certain conditions, that it caused a certain amount of harm, and that it deserves attention soon. The first two are observations. The third is an assessment. The fourth is a request. Mixing them into a single paragraph of prose is how a report becomes unactionable.
A well-formed report keeps the observation and the assessment visibly separate. The observation is the reproduction: what the tester did, what the build was, what appeared instead of what was expected. The assessment is the severity judgment, and it should be argued from the observation rather than asserted alongside it. If the claim is that the defect corrupts saved data, the report should show the corrupted data, not merely state that corruption is possible.
The request is the priority ask, and it belongs to the reporter only as a suggestion. A tester can note that a defect blocks a release candidate or affects a contractual commitment, but the scheduling decision belongs to whoever owns the queue. When reporters write priority as though it were a fact, reviewers either rubber-stamp it or ignore it, and both outcomes erode the field. The cleanest reports read like a short argument: here is what happens, here is how bad it is when it happens, here is why it might matter now, and here is the evidence for each.
03 Severity versus priority
Severity is a property of the defect in the product. It answers a narrow question: if this occurs, how much damage does it do? A crash that loses unsaved work is severe. A corrupted record that propagates into downstream reports is severe. A misaligned button is not, no matter where it sits. Severity should be stable across releases, because the product's behavior under the failure does not change just because a deadline moved. Two reviewers looking at the same reproduction should arrive at roughly the same severity, and when they do not, the disagreement usually points to a missing detail in the report rather than to a genuine philosophical split.
Priority is a property of the work, not the defect. It answers a different question: when will we fix this, relative to everything else? Priority depends on release timing, customer exposure, workaround availability, the cost of the fix, and the cost of delay. A severe defect in a feature nobody uses yet can be low priority. A trivial defect on a launch screen the day before launch can be high priority. Neither of those is a contradiction, and treating them as contradictions is the root of the broken backlog.
The practical rule is that severity is assigned by the people closest to the failure and priority is assigned by the people who own the schedule. When one person sets both without discussion, the fields drift toward each other and become redundant. When they are set separately and then reviewed together, the interesting cases surface: high severity with low priority needs a documented reason, and low severity with high priority needs a visible trigger such as a launch date or a customer commitment.
04 Writing steps someone else can follow
Reproduction steps are the part of the report most often written for the author rather than the reader. The author already knows the context, so the steps omit the account state, the feature flag, the data setup, and the exact build. A reader then follows them, fails to reproduce, and closes the report as not reproducible. The defect survives, unowned, and the next reporter files it again.
Write steps as a sequence a stranger can execute without asking questions. Start from a known state, name the build or version, and list each action in order with the exact input used. If the defect depends on a particular account, dataset, or configuration, say so and describe how to obtain it. If the failure is intermittent, say that too, and record how many attempts produced it. Intermittency is information, not a weakness in the report.
End with the observed result and the expected result, stated plainly and separately. The expected result is where most hidden assumptions live; writing it out forces the reporter to check whether the expectation is actually correct. Keep the steps minimal. Every extra action is a place where the reader can diverge, and every divergence is a chance to dismiss a real defect. A short, precise sequence that reliably triggers the failure is worth more than a long narrative that describes the surrounding session. When the steps are right, severity becomes arguable from evidence rather than from opinion, and triage gets faster for everyone.
05 Running the triage queue
Triage is a routing decision, not a debate about whether the defect is real. The queue exists to move reports to the right owner with enough information to act, and to send incomplete reports back with a specific request. A healthy triage session is short because the reports arriving in it are already well formed. A session that runs long is usually compensating for reports that skipped the discipline described above.
At review, confirm the reproduction first. If it cannot be reproduced, the report goes back with a precise question rather than a rejection. Then set severity from the observed damage, set priority from the schedule and exposure, name an owner, and record the decision. The owner matters more than the exact label; a report with a slightly wrong severity and a clear owner will get fixed, while a report with a perfect severity and no owner will sit. Affected area should be narrow enough to route correctly and broad enough to catch related symptoms, so a fix can address the family rather than the instance.
Status is the field that keeps the queue honest. It should reflect where the work sits, not how important anyone feels the defect is. A report marked fixed is not verified until someone reproduces the original failure on the corrected build and confirms it no longer occurs. Keep the triage decisions visible in the report so later readers can see why priority was set as it was. Decisions that are recorded can be revisited; decisions that live only in a meeting cannot.
06 When a defect comes back
A reopened defect is not a failure of the process; it is the process working. The fix did not hold, the reproduction was incomplete, or the original diagnosis addressed a symptom rather than the cause. The useful response is to treat the reopening as new evidence and update the report rather than starting a fresh one. Preserve the history, add the new reproduction, and note what changed between the build that appeared fixed and the build where it returned.
Recurrence often reveals that the original steps were too narrow. The first report captured one path to the failure; the reopening captures another. Merge them into a single description that covers both, and re-examine severity in light of the broader trigger. A defect that returns through a second path may be more severe than the first assessment suggested, because the underlying condition is wider than it appeared. Priority may also shift if the recurrence lands in a release window that the original report predated.
Avoid the temptation to close a reopened defect as a duplicate of itself or to quietly reassign it. Each of those moves hides the signal that the fix was incomplete. Instead, record the recurrence, update the affected area if the second path touches a different surface, and confirm whether the original verification was adequate. Over time, recurrence patterns point at weak spots in the test approach: areas where reproduction is hard, where fixes are verified shallowly, or where the same class of defect keeps returning under new symptoms.
07 Frequently asked questions
Can a defect be high severity and low priority? Yes, and this is one of the most common and most misunderstood combinations. A severe failure in a feature that is not yet released, or that has a safe workaround, can reasonably wait. The important thing is that the low priority is a recorded decision with a reason, not an accident of the label. When the feature approaches release, the priority should be revisited rather than rediscovered.
Can a defect be low severity and high priority? Also yes. A cosmetic problem on a screen that every customer sees first can justify immediate attention because of exposure, not damage. The severity field still tells the truth about the defect; the priority field tells the truth about the schedule. Keeping both visible prevents the team from pretending the cosmetic issue is a crash in order to justify fixing it.
Who decides priority? The people who own the schedule and the commitments, informed by the severity assessment and by anyone who can speak to exposure. Testers should supply evidence and context, not final scheduling calls. Who decides severity? The people closest to the failure, ideally with a second reviewer for disagreements. What if the two fields always agree in your backlog? That is a signal to check whether one person is setting both without discussion, which usually means one of the fields has stopped carrying independent information.