6.5Common Mistakes

1. Using "Severity" When You Mean "Priority"

"This is a severity 1 bug, fix it now!"

Severity 1 means the bug is technically devastating. Whether to fix it now depends on priority, which depends on business context. A severity 1 bug in a feature used by 3 internal users may be P2.

2. Inflating Severity to Get Attention

Marking every bug as "Critical" to ensure it gets fixed is counterproductive. When everything is critical, nothing is critical. The team stops trusting severity ratings, and truly critical bugs get lost in the noise.

3. Using a Single Scale

Some teams use only one field ("High/Medium/Low") for both severity and priority. This forces trade-offs that obscure information. A bug can be simultaneously "high severity" and "low priority" — a single scale cannot represent this.

4. Never Updating Priority

A P3 bug filed three months ago may now be P1 because a major customer complained about it. Priority should be reassessed during triage meetings.