I agree. To assign a priority, the PM has to know exactly what happens in context. "Severity" doesn't help with that or with any other stage of reporting, tra

I agree. To assign a priority, the PM has to know exactly what happens in context. "Severity" doesn't help with that or with any other stage of reporting, tracking, fixing, and testing. I could see where a severity dimension could be useful retrospectively if paired with classification. For example, you could look back and say, why did we have a big spike in severity 1 security bugs in Q4? However, I think I'd rather not have the dimension available than be forced to set it on every single bug on the off chance it will help with analysis later. "I bet we can do cool stuff with this someday" is never a good reason to add process overhead. If somebody retrospectively categorizes and summarizes tickets by some dimension and proves that it yields useful information, that could be grounds for asking engineers to track it in the future.