I came across a good post today that talks about separating defect priority and severity. The related post is older now but the concept still stands. I have implemented this in one way or another on my engagements but I liked the simplicity outlined in Ronny’s post.

Differentiate Priority and Severity. The effect of a bug on the software does not automatically correlate with the priority for fixing it. A severe bug that crashes the software only once in a blue moon for 1% of the users is lower priority than a mishandled error condition resulting in the need to re-enter a portion of the input for every user every time. – Ronny De Winter

He outlines the 4 point severity system next.

“Severity 1 is a crash or anything that loses persistent data , i.e., messing up your files on disk. Sev 2 is a feature that doesn’t work. Sev 3 is an aspect of a feature that doesn’t work. Sev 4 is for purely cosmetic problems, misspellings in dialogs, redraw issues, etc. – Ronny De Winter

Good stuff!