Our product owners want to prioritize the backlog based on requirement risk scores, but we’re struggling to make this visible in Jira Data Center. We’ve added a numeric custom field called “Risk Score” (1-10) to our requirement issues, and we’re trying to approximate test coverage by counting linked test case issues.
The challenge is creating backlog views that sort by risk while showing coverage metrics. We can’t install marketplace plugins due to company policy, so we need a native solution using filters and dashboards. Has anyone built something similar?
Here’s our current risk field setup:
Custom Field: Risk Score (Number)
Values: 1-10 (10 = highest risk)
Applied to: Requirement issue type
The backlog view doesn’t naturally surface this data, and our POs are manually checking each requirement. Any suggestions for making risk-based prioritization more visible?
We use a hybrid approach. Keep ranking enabled for sprint planning, but create a separate “Risk Review” board with ranking disabled that sorts by Risk Score. POs use the risk board for backlog grooming sessions, then move items to the ranked sprint board. We also built a gadget dashboard showing risk distribution and coverage percentages using JQL and pie charts.
Let me synthesize the approaches here into a complete solution for your risk-based backlog prioritization.
1. Risk Score Custom Field Configuration
You’ve already set up the numeric Risk Score field correctly. Ensure it’s visible on the backlog card layout by adding it to the card fields in Board Settings → Card Layout. This makes risk scores visible at a glance without opening issues.
2. Approximating Test Coverage via Linked Issue Counts
Since native Jira DC doesn’t provide real-time link counts, use automation to maintain a “Test Coverage Count” custom field:
Create a Number custom field: “Test Coverage Count”
Set up an automation rule triggered when test case links are added/removed
Rule action: Edit the requirement issue to update the count field
Schedule a daily reconciliation rule that recalculates all counts using JQL queries
This gives you sortable coverage data. It’s not instant but sufficient for backlog planning.
3. Backlog View Configuration Using Filters and Dashboards
Create multiple board configurations rather than trying to make one board do everything:
Risk Prioritization Board:
Create a saved filter: `project = YOUR_PROJECT AND type = Requirement ORDER BY “Risk Score” DESC, “Test Coverage Count” ASC
Create a Scrum board using this filter
Disable ranking (Board Settings → General) to respect the filter’s sort order
Use this board exclusively for backlog grooming and risk assessment
Sprint Planning Board:
Keep your existing ranked board for sprint planning
Enable ranking for drag-and-drop prioritization
POs transfer high-risk items from the risk board to this board for sprint commitment
4. Dashboard for Executive Visibility
Build a dashboard with these gadgets:
Two Dimensional Filter Statistics: Shows risk score vs test coverage in a heat map
Filter Results: Display top 20 high-risk, under-tested requirements using JQL:
type = Requirement AND "Risk Score" >= 7
AND "Test Coverage Count" < 5
ORDER BY "Risk Score" DESC
Pie Chart: Risk score distribution across the backlog
Created vs Resolved Chart: Track velocity of addressing high-risk requirements
5. Workflow Integration
Add a validator to your requirement workflow that warns when moving to “Ready for Development” if Risk Score ≥ 7 and Test Coverage Count < 3. This enforces coverage thresholds for risky requirements.
POs review the Risk Prioritization Board (sorted view)
Use dashboard to identify coverage gaps
Create test cases for under-covered high-risk requirements
Automation updates coverage counts overnight
Next session shows improved coverage metrics
Move adequately covered high-risk items to sprint planning board
This approach works entirely within native Jira DC capabilities. The key is accepting that you need multiple boards and dashboards rather than a single perfect view. The automation-maintained coverage count is the critical piece that makes risk-based prioritization actionable.
The main limitation is the delay in coverage count updates, but for backlog planning (not real-time sprint execution), hourly or daily updates are sufficient. If you need more sophisticated risk-coverage matrices, you’d need to export to external tools, but this solution handles 90% of use cases within Jira.
Board ordering is tricky in DC. The board respects its filter’s ORDER BY clause only if you disable ranking. Go to Board Settings → General → uncheck “Enable Ranking”. Then your filter’s ORDER BY Risk Score DESC will work. Warning: this breaks drag-and-drop reordering, so it’s a trade-off between manual ranking and risk-based sorting.
For coverage visibility, you’re limited without plugins. What we do is create a calculated custom field updated via automation. When a test case links to a requirement, an automation rule increments a “Test Count” number field. It’s not real-time but runs every hour. This gives you a sortable coverage metric alongside risk score. You can then build a two-dimensional view using JQL and color-coding in dashboards.
For linked issue counts, there’s a workaround using JQL functions. Create a dashboard filter that uses issueFunction in linkedIssuesOf() to count test links. You can’t put this directly in a custom field, but you can build a dashboard gadget that shows requirements with their risk scores and uses the filter results to approximate coverage. We export this weekly to Excel for PO review meetings.
Here’s a sample JQL for high-risk, low-coverage items:
type = Requirement AND "Risk Score" >= 8
AND issueFunction in linkedIssuesOf("type = Test") < 3
It’s not perfect, but gives you a starting point for prioritization conversations.
I’ve tackled this exact problem. The key is using board filters combined with quick filters. Create a saved filter that orders by Risk Score descending, then configure your Scrum board to use that filter as the board query. You can add quick filters for different risk ranges (8-10, 5-7, etc.) to let POs toggle views quickly.
Thanks Mike. We tried that but the board still shows sprint grouping first, then priority. How do we get risk score to override the default ordering? Also, any ideas on surfacing the test coverage count (linked issues) directly in the backlog view?