Don’t Confuse a Bug’s Priority with Its Severity
> a P0 (Blocker) bug is a ship-stopper which has to be fixed before the next release can happen. P1s (Critical) are important but not something we’d stop a release for, while P2s (Medium,Low) represent pretty much anything that will only be fixed when our development team has cleared all P0 and P1 bugs> It’s important to note that a bug’s priority shouldn’t be confused with its severity, which exists as an entirely different dimension... ‘Severity’ to represent a (somewhat) objective assessment of a bug’s impact to the functionality of the system. From Critical representing major crashes or hangs, to Minor functional issues or purely Cosmetic blemishes. While a QA engineer will classify a bug’s Severity at creation time, it’s the PM who assigns the Priority at the time of triage based on their knowledge of the client’s business and product requirementsI don't see the benefit in having severity and priority as 2 distinct dimensions. Given a specific priority, what additional benefit do you get from having a severity label as well? Based on the author's description, I can't think of any.If the goal is to better communicate what "type" of bug it is, using an enum classification (eg, cosmetic vs crash vs data-corruption) would be more appropriate than a numeric scale.