01 Overview
A triage queue is not a list of bugs. It is a decision pipeline. Every item that enters the queue is waiting for a routing decision: fix now, fix later, reject, merge with another report, or send back for more information. When that decision never gets made, the queue stops being a pipeline and becomes a landfill. Reports pile up, engineers stop trusting the queue, and testers stop filing because nothing seems to happen. The defect ledger becomes a record of neglect rather than a tool for shipping.
The root cause is almost never a lack of bugs or a lack of testers. It is a lack of ownership over the sorting itself. Someone must be accountable for moving each report from unread to routed. That person does not have to be a manager or a lead. It can be a rotating role, a dedicated triage owner, or a small group that meets regularly. What matters is that the responsibility is explicit, time-boxed, and visible. Without that, severity and priority become opinions that nobody records, and repro steps become a scavenger hunt for whoever eventually picks up the ticket.
This article treats triage as a craft. It covers what a report is actually claiming, how severity differs from priority, how to write steps that another person can follow, how to run the queue, what to do when a defect comes back, and the questions that come up most often. The goal is not a perfect process. The goal is a queue that keeps moving, because a moving queue is the only kind that helps a team decide what ships.
02 What the report is actually claiming
Every defect report makes a claim, whether or not the author realizes it. The claim is not simply that something is broken. The claim is that a specific behavior, under specific conditions, produces a specific result that differs from what the team intended. If the report does not make that claim clearly, triage cannot evaluate it. The first job of the triage owner is to extract the claim from the text, and the first job of the reporter is to make that extraction easy.
A useful report answers three questions without requiring a meeting. What did you do? What did you expect? What actually happened? Those three answers form the core of the claim. Everything else, such as screenshots, logs, environment details, and frequency, is supporting evidence. When the core is missing, the report is not ready for triage. It is ready for a conversation, and that conversation should happen before the report enters the queue, not after it has been sitting there for a week.
Testers and engineers often disagree about what counts as a defect because they are evaluating different claims. One person sees a crash and calls it a defect. Another sees a crash that only happens with an unsupported configuration and calls it expected behavior. Neither is wrong until the team agrees on the intended behavior. Triage is where that agreement gets recorded. If the intended behavior is unclear, the routing decision should be needs more information, not accept or reject. A report that cannot state its claim cannot be prioritized, and a queue full of unclear claims will stall no matter how many people are assigned to it.
03 Severity versus priority
Severity describes how much damage a defect causes. Priority describes when the team intends to fix it. These are related but not identical, and confusing them is one of the most common reasons triage decisions get relitigated. A defect can be high severity and low priority, such as a crash that only occurs in a deprecated workflow with almost no users. A defect can be low severity and high priority, such as a typo on the checkout page that makes the company look careless during a major launch. The team needs both axes to make a good routing decision.
Severity should be assessed against the affected area and the user impact, not against how annoying the bug is to reproduce. A defect that corrupts data is severe even if it takes twenty steps to trigger. A defect that misaligns a button is not severe even if it happens on every page. The triage owner should ask what happens if this defect ships unchanged. If the answer is data loss, security exposure, or a broken core workflow, severity is high. If the answer is cosmetic or confined to an edge case, severity is lower. This assessment should be recorded, not debated every time someone new reads the ticket.
Priority is a scheduling decision, and it belongs to the team that owns the roadmap. A tester can recommend a priority, but the final call should reflect what the team is willing to delay in order to fix this defect. That means priority is always relative. A medium-priority defect in a quiet week may be fixed immediately. The same defect during a release crunch may wait. The triage queue should make that trade-off visible, so the team can see what it is choosing to ship with. Severity tells you what the defect does. Priority tells you what the team is going to do about it, and when.
04 Writing steps someone else can follow
Reproduction steps are not a narrative. They are a recipe. The shortest reliable path to the defect is almost always better than a long, detailed story about how the tester discovered it. A good set of steps starts from a known state, lists the minimum actions needed to trigger the problem, and ends with the observed result. If the steps require knowledge that lives only in the reporter's head, they are not finished. The test is simple: can another person follow them without asking a question?
Start by naming the starting state. Which build, which account, which data, which configuration? If the defect only appears after a specific sequence of prior actions, say so. Then list the actions in order, one action per step, using the same words the interface uses. Avoid vague verbs like click around or try to reproduce. If a step depends on timing, network conditions, or a particular device, state that dependency explicitly. Finally, describe what happened and what was expected. The expected result is not optional. Without it, the reader cannot tell whether the observed behavior is a defect or a feature.
A common mistake is to include too much. Long steps with irrelevant detours make it harder to isolate the cause. If the reporter is not sure which step matters, they can note that uncertainty and provide a minimal version alongside a fuller version. Another mistake is to assume the reader has the same environment. Mention the browser, operating system, build number, and any feature flags that affect the affected area. These details are not bureaucracy. They are what allows an engineer to reproduce the defect on the first try instead of the fifth. Good repro steps respect the reader's time, and that respect is what keeps the triage queue moving.
05 Running the triage queue
Running the queue means making decisions on a predictable cadence. The exact cadence depends on the team, but the principle is the same: reports should not wait indefinitely for a routing decision. A daily or every-other-day pass is usually enough for most teams. The triage owner reviews new reports, confirms that each one states a clear claim, assigns severity and a recommended priority, and routes it. Routing options include accept for the current cycle, defer to a later cycle, reject as working as intended, mark as duplicate, or send back for more information. Each decision should be recorded in the report itself so the history is visible.
The triage owner is not a gatekeeper who must know everything. They are a facilitator who knows when to pull in the right person. If a report touches a component with a clear owner, the triage owner can route it to that owner for a severity assessment. If a report challenges intended behavior, the triage owner can ask the product owner or the relevant engineer to confirm the expectation. The goal is not to resolve every question in the meeting. The goal is to leave every report with a next action and an owner. A report with no next action is not triaged, even if it has been read.
Queue health is visible in simple ways. How many reports are waiting for a first decision? How many are waiting for more information from the reporter? How many have been deferred more than once? A queue that grows without bound is a signal that ownership is unclear or that the cadence is too slow. A queue that empties too quickly may be a signal that reports are being rejected without enough scrutiny. The triage owner should watch these patterns and adjust. The point of the queue is not to be empty. The point is to make deliberate decisions about what ships, and to be able to explain those decisions later.
06 When a defect comes back
A defect that comes back after being closed is not a failure of the process. It is information. Either the fix was incomplete, the reproduction steps missed a condition, or the original triage decision was based on a misunderstanding. The worst response is to reopen the ticket silently and let it sit. The better response is to treat the return as a new triage event with the old ticket as context. What changed? What was missed? Is this the same claim or a different one? The answers determine whether the ticket should be reopened, merged, or replaced.
If the defect returns because the fix did not cover all affected areas, the triage owner should update the affected area and severity assessment. If it returns because the repro steps were incomplete, the reporter should add the missing conditions so the next attempt is more reliable. If it returns because the team decided the behavior was acceptable and users disagreed, the triage decision itself needs to be revisited. Reopening without that reflection just restarts the same cycle. The goal is to learn enough from the return that the next fix is more likely to hold.
Returns also affect priority. A defect that comes back after being deferred may deserve a higher priority than it had before, because the cost of leaving it unfixed has now been demonstrated. That does not mean every return is urgent. It means the team should look at the pattern. A single return may be noise. Repeated returns in the same affected area suggest a deeper problem with how that area is tested or understood. The triage queue should capture that pattern, not hide it. When a defect comes back, the queue gets a chance to be more accurate. Taking that chance is what separates a working triage process from a ticket archive.
07 Frequently asked questions
Who should own triage? The owner should be someone with enough context to route reports and enough authority to keep the cadence. That can be a tester, an engineer, a lead, or a rotating role. The important thing is that the responsibility is named and that the person has time to do it. If triage is added to someone's plate without removing anything else, the queue will stall. Ownership without capacity is just a title.
How many severity levels should we use? Use as few as your team can apply consistently. Three or four levels are usually enough. More levels create debates about whether something is a three or a four, and those debates do not help anyone ship. The same is true for priority. The value of a scale is in the consistency of its use, not in its granularity. If two people can look at the same defect and assign the same severity most of the time, the scale is working.
What if the reporter and the triage owner disagree? The disagreement is usually about the claim, not about the person. Go back to the three questions: what did you do, what did you expect, what happened? If the answers are clear, the severity and priority discussion becomes easier. If they are not clear, the report needs more information before it can be triaged. Disagreement is a signal that something in the report is ambiguous, and ambiguity is fixable.
How do we keep the queue from growing forever? Set a cadence, keep it, and measure the age of the oldest untriaged report. If that age keeps growing, the cadence or the ownership is not working. You do not need a complex dashboard. You need a visible number and a person who cares about it. The queue dies when nobody owns the sorting. It lives when someone does, and when the team treats that ownership as part of the work rather than an interruption to it.