Severity vs priority

These two fields answer different questions and belong to different people. Severity is a technical assessment of impact: what stops working, how much data is affected, whether a workaround exists. A tester or engineer sets it from evidence and it should not move because of a deadline. Priority is a scheduling decision about when the fix happens, and it belongs to whoever owns the roadmap. Collapsing them into one field, which a surprising number of trackers encourage, destroys the ability to have either conversation properly.

The reason to keep them separate becomes obvious at the corners. A cosmetic typo is trivially severe and occasionally the highest priority in the backlog, because it is the company name misspelled on the pricing page an hour before a launch. A complete crash is maximally severe and sometimes low priority, because it needs a configuration nobody outside a lab will ever produce. Teams that maintain one combined field spend their triage meetings arguing about a number instead of about the product.

Making the two fields behave

• Define each level with an observable test rather than an adjective. "Major" means nothing consistent across three people; "blocks a documented business process with no workaround" can be checked.
• Let severity be set by the reporter and priority by the owner, and treat a disagreement about severity as a factual dispute to be settled with evidence rather than seniority.
• Resist the drift where everything arrives as high. Once most of the backlog is urgent the field has stopped carrying information and triage reverts to whoever asks loudest.
• Review the pairs that look strange. High severity sitting at low priority for months is either a risk somebody has accepted in writing or a decision nobody actually made.

If your tracker offers a single "importance" field, the scheduling conversation will quietly overwrite the technical assessment, and the record of how bad the defect actually was is lost.