7.6.3. Priority

Two key attributes are used to evaluate the impact and urgency of a defect:

In defect management, understanding the difference between severity and priority is crucial. Severity refers to the technical impact that a bug has on the system. For example, a critical bug might cause the entire application to crash, whereas a trivial bug might just display a small typo. On the other hand, priority reflects the urgency of fixing the bug from a business standpoint. For instance, a bug that's causing major sales loss would have high priority, even if it is technically not the most severe bug on the system. The assessment of severity is typically done by QA testers, while product managers determine the priority.

Think of severity like the damage a car has after an accident. A car with a broken engine (critical severity) needs immediate attention but may be less impactful if the vehicle isn't being used that day. Conversely, priority is like deciding which car to fix first based on how often it is used. A working car with a minor fender bender (low severity) could be prioritized for repair because it's used daily.

🎯 Severity Examples:

• Critical: App crashes on login
• Major: Wrong calculation in an invoice total
• Minor: UI alignment issue on help page
• Trivial: Typo in footer text

Severity levels categorize defects based on the impact they have on the application. Critical issues must be addressed immediately as they prevent the application's basic functions. Major issues, while serious, might not halt application functionality but require prompt attention. Minor issues are less disruptive, such as alignment issues that affect aesthetics but not usability. Trivial issues are usually cosmetic, like typos, that have very low impact on functionality and can wait for future updates.

Imagine you're running a restaurant. A critical issue would be a broken fridge that spoils all your food—this needs immediate repair. A major issue might be an unclean dining area, which affects customer experience but can wait a bit. A minor issue could be a table that wobbles slightly, still usable but not ideal. Finally, a trivial issue would be a small crack in a plate that won't affect its use at all.

🎯 Priority Examples:

• High: Fix required before release
• Medium: Can be scheduled in next sprint
• Low: Cosmetic issue, fix in future release

Priority levels indicate the order in which defects should be addressed. A high priority defect is one that needs to be resolved immediately because it may hinder a release or essential function. Medium priority defects are important but can be worked on later, typically in the next development cycle or sprint. Low priority defects, often cosmetic or minor, can be scheduled for a future update without immediate consequences.

Consider a school setting where a teacher needs to prioritize student issues. A student's health emergency (high priority) needs immediate action before anything else. An assignment question that needs clarification (medium priority) can wait until the next class. Lastly, a student's request for a new pencil (low priority) can be handled when there's extra time.

🔄 A defect can be High Severity + Low Priority, or Low Severity + High Priority, depending on business needs.

It's important to note that a defect's severity and priority can vary independently. For instance, a critical issue that prevents users from logging into an app (high severity) might temporarily be classified as low priority if the issue occurs during off-peak hours. Conversely, a minor bug that garners public attention—like a spelling error in a highly visible app promo—might be given high priority for correction, even if its technical severity is trivial.

Imagine a city experiencing a power outage (high severity) during a holiday weekend when people are away (low priority) compared to a streetlight that has a faulty bulb (low severity) but is on a main road and urgently needs fixing (high priority) to ensure safety.

--