Our release planning burndown charts are showing incorrect defect counts, which is causing confusion in executive reports. The issue is that Resolved bugs are still being counted in the remaining work, making it appear that we have more open defects than we actually do.
We’re using the standard Burndown widget on our release dashboard, configured to track Bug work items for Release 2024.4. The chart should only count Bugs in ‘New’ or ‘Active’ states, but it’s including ‘Resolved’ Bugs as well.
Example data from yesterday:
- Actual open Bugs (New + Active): 23
- Burndown chart showing: 37
- Difference: 14 Bugs in ‘Resolved’ state
The widget configuration appears correct:
Work Item Type: Bug
States: New, Active
Release: 2024.4
When I run a manual WIQL query filtering for New and Active states, I get the correct count of 23. But the burndown chart consistently shows higher numbers. Is there a known issue with Analytics views not properly excluding Resolved state? Do we need to tune the burndown query or adjust the widget configuration differently?
Burndown charts have a time-based component. If Bugs were Resolved during the current sprint/release but after a certain date, they might still appear in historical data points on the chart. The chart shows the state of work items at each point in time, not just the current state. This could explain the discrepancy if you’re looking at cumulative counts.
Analytics views can take up to 30 minutes to refresh after configuration changes. Also, make sure you’re using the correct date range in your burndown. If your release spans multiple sprints and some Bugs were resolved early but later reopened, the historical data might be skewing your current counts. Use the ‘As of’ date filter to ensure you’re seeing current state.
Check your Analytics view definition, not just the widget configuration. The widget reads from an Analytics view, and that view might have different state filters than what you’ve configured in the widget. Navigate to Analytics views and verify the state exclusion rules.
Checked the Analytics view - it’s set to ‘All’ states by default, which explains part of the issue. But even after updating it to exclude Resolved, the chart is still showing inflated numbers. Could there be a caching delay?
The root cause of your burndown miscalculation lies in how Azure DevOps Analytics processes work item state history and widget configuration interactions. Here’s the comprehensive solution:
Burndown Query Tuning:
The Burndown widget uses a time-series query against the Analytics service, which maintains historical snapshots of work item states. Your issue stems from three potential misconfigurations:
- Analytics View State Filter: The view must explicitly exclude terminal states
- Widget Date Range: Historical data points may include Bugs that were later Resolved
- Release Association Logic: How Bugs are linked to the release affects counting
Analytics Views Configuration:
Create a custom Analytics view specifically for your burndown:
- Navigate to Analytics Views in your project
- Create new view: ‘Release 2024.4 Active Defects’
- Configure filters:
- Work Item Type = Bug
- State NOT IN (Resolved, Closed, Removed)
- Release Tag = 2024.4 OR IterationPath UNDER Release2024.4
- Enable ‘Track history’ to maintain time-series data
- Set refresh frequency to ‘Every 4 hours’ for near-real-time updates
State Exclusion WIQL:
For validation, use this WIQL query to verify your Bug count matches the burndown:
SELECT [System.Id], [System.Title], [System.State]
FROM WorkItems
WHERE [System.WorkItemType] = 'Bug'
AND [System.State] IN ('New', 'Active')
AND (
[System.Tags] CONTAINS '2024.4'
OR [System.IterationPath] UNDER 'Project\Release2024.4'
)
AND [System.ChangedDate] >= @Today - 60
Run this query and compare the count to your burndown. If they match, your Analytics view is correctly configured. If not, there’s a filter mismatch.
Widget Configuration Best Practices:
-
Use Custom Analytics View: Don’t rely on default views
- Widget Settings > Data Source > Select your custom view
- This ensures consistent state filtering
-
Set Explicit Date Range:
- Start Date: Release 2024.4 start date
- End Date: Release 2024.4 target completion
- This prevents historical data pollution
-
Configure Burndown Type:
- Choose ‘Count of Work Items’ not ‘Sum of Story Points’
- Ensures you’re counting Bugs, not estimating effort
-
Enable ‘Show Completed Work’:
- Toggle OFF if you only want remaining work
- Toggle ON to see the complete burndown including resolved items
Common Pitfalls:
- State Transitions: If Bugs transition through multiple states (New → Active → Resolved → Closed), ensure your Analytics view excludes ALL terminal states
- Reopened Bugs: Bugs that were Resolved then reopened appear twice in history. Use ‘Current State’ filter, not ‘Ever Been In State’
- Release Tags vs IterationPath: Decide on ONE method for associating Bugs to releases. Mixing both causes double-counting
Executive Reporting Fix:
For your executive reports, create a separate dashboard with:
- Custom Analytics view (as described above)
- Burndown widget using that view
- Bug count widget showing current state (New + Active)
- Bug trend widget showing resolution rate over time
This provides a complete picture: remaining work (burndown), current snapshot (count), and velocity (trend).
Validation Process:
After reconfiguring:
- Wait 30 minutes for Analytics to refresh
- Run your WIQL query for current count
- Check the burndown chart’s latest data point
- Verify they match within ±1 (accounting for real-time state changes)
- Review historical data points to ensure Resolved Bugs aren’t inflating past counts
The 14-Bug discrepancy you’re seeing is almost certainly due to the default Analytics view including Resolved state. Once you switch to a custom view with explicit state exclusions, the burndown will accurately reflect only New and Active Bugs.