I notice this sentence: > Effective bug triage is an essential hygiene and success factor for anyone managing a software release. I could not agree more. To s

I notice this sentence: > Effective bug triage is an essential hygiene and success factor for anyone managing a software release. I could not agree more. To some extend, it applies to all change requests. That said, there is no need to be too specific in your change request specification. Where I work, we have setup only a few parameters to help us triaging several hundreds of CR: - Priority: Low, Medium, High - Type: Add (new feature), Enhancement (small change on an existing feature) and bug - env: Production, Acceptance, Development, ... In 99% of the case, this is completely sufficient. As said by others, adding severity does not add useful information on a bug triage (it may provide information on the bug itself). If there is a data loss involved but the client is fine with it, that would never lead to a high priority bug. If the client care about its data, then be sure the priority will be high. It means that bug triage really is priority assignment (no matter the severity). In our workflow, only high priority bugs (usually hitting the production) are subject to hot-fixes. All other tickets go into carefully crafted milestones (a package to deliver). As all CRs belonging to the same milestone are delivered together, they actually all share the same priority which becomes the priority of the milestone compared to other milestones. (edited for formatting)