We’re considering replacing our simple Sev 1-4 scale with a risk-based model: Impact (High/Med/Low) and Likelihood (High/Med/Low) fields that compute a Risk Score. The idea is to better prioritize defects that are both high-impact and likely to occur, rather than just flagging everything as ‘critical’.
Has anyone moved to this model? How do you handle the extra triage overhead-asking testers to estimate likelihood feels subjective. Also curious if you automate the risk calculation or if teams do it manually. And does the risk score actually drive sprint planning, or does it just become another ignored field?
Honestly, we tried this and abandoned it. The triage meetings took twice as long because people debated whether something was ‘Medium Likelihood’ or ‘High Likelihood’. We went back to Severity + Priority (business impact). The risk model sounds great in theory, but in practice, most teams don’t have the discipline to use it consistently. If you do go this route, make sure you have very clear rubrics and maybe even a decision tree poster on the wall.
One thing to watch: if your defect volume is high, asking for two extra fields per bug adds up. We found testers started rushing through the fields just to close the ticket. Consider defaulting Likelihood to ‘Medium’ and only requiring an explicit choice for High Impact defects. That way, your critical bugs get the full risk assessment, but minor UI glitches don’t slow down the triage queue.
The key benefit we saw was in release go/no-go decisions. Instead of arguing about whether a Sev-2 should block release, we look at the Risk Exposure dashboard. If we have three High Risk defects (high impact, high likelihood), that’s a clear signal to delay. If they’re all Low Likelihood, we might ship with workarounds. The risk model gives you a more nuanced conversation than a binary severity flag.
We implemented this last year. Impact is straightforward (based on user count affected), but Likelihood was tricky. We ended up using occurrence frequency: ‘Always’, ‘Frequent’, ‘Occasional’, ‘Rare’. Testers found that easier to judge than abstract probability percentages. Risk Score is auto-calculated via a ScriptRunner post-function: High Impact + Always = Critical Risk, and so on. It works, but you need clear definitions or every bug becomes ‘High Impact’.
We use it successfully, but only because we automated the calculation. Impact and Likelihood are dropdowns, and an automation rule computes Risk Exposure as a number (1-9 scale). High-risk defects (score 7+) automatically get added to the ‘Hardening Sprint’ backlog via a board filter. This way, the risk model directly drives what gets fixed in the stabilization phase. Without that automation, it would’ve been just another data point nobody looks at.
Here’s what we learned after two years with risk-based prioritization:
Impact and Likelihood Fields: We use custom select lists. Impact has three tiers: High (affects >50% users or core functionality), Medium (affects specific workflows or <50% users), Low (cosmetic or edge cases). Likelihood uses frequency: Always (100% repro), Frequent (>50% of attempts), Occasional (<50%), Rare (hard to reproduce). This gives testers objective criteria instead of gut feelings.
Automation Rules: We set up an automation rule that fires on defect creation or field update. It calculates Risk Exposure as a number: High Impact + Always = 9, High + Frequent = 8, down to Low + Rare = 1. The rule updates a custom number field called ‘Risk Score’. We then have a saved filter for ‘High Risk Defects’ (score ≥7) that feeds into our Hardening Sprint board.
Triage Overhead: Initially, it added 2-3 minutes per defect. We reduced this by making Likelihood optional for Low Impact bugs-they default to Medium Likelihood and get a mid-range score. Only High Impact defects require explicit Likelihood assessment. This cut triage time by 40% while still flagging the truly dangerous bugs.
Driving Sprint Planning: The risk score is now our primary filter for hardening sprints. Product Owner reviews the High Risk backlog weekly and decides which defects to pull into the next sprint. We also built a dashboard showing Risk Exposure trend over time (sum of all open risk scores). If the trend line spikes, we know we need to allocate more capacity to defect remediation.
Balancing Data Richness: Don’t over-engineer. We tried adding ‘Detection Phase’ and ‘Customer Segment’ fields to refine risk further, but teams ignored them. Stick to two fields (Impact, Likelihood) and automate the score. The simpler your model, the more likely people will use it consistently.
One Gotcha: Make sure your automation rule recalculates risk when either field changes. We had a bug where updating Impact didn’t refresh the score, leading to stale risk data. Also, consider adding a ‘Risk Justification’ comment field for High Risk defects so there’s a record of why something was deemed high likelihood-useful during retrospectives and post-mortems.