Our organization is revamping how we forecast defect resolution capacity for release planning, and I’m curious what velocity metrics other teams find most predictive. We currently track defect burndown rate (defects closed per sprint), but I’m wondering if throughput metrics or escape rate trends would give us better forecasting accuracy.
The challenge is that burndown alone doesn’t account for new defects discovered during the release cycle, which can make our projections overly optimistic. We’ve been experimenting with dashboard configuration in ELM to visualize different KPI combinations, but I’m not sure how to weight these metrics for decision-making. What’s worked well for your release planning processes?
One metric we found valuable is defect age distribution - what percentage of your backlog is fresh (under 2 sprints) versus stale (over 6 sprints). This helps predict whether your velocity will hold steady or drop as you tackle older, more complex defects. We built a custom dashboard widget that shows throughput velocity segmented by defect age buckets. Newer defects typically close 2-3x faster than old ones, so your forecast needs to account for backlog composition, not just raw velocity numbers.
After managing releases across multiple products, I’ve settled on a tiered approach to velocity metrics that addresses many of the points raised here. For dashboard configuration, we organize metrics into three layers:
Tier 1 - Capacity Planning (60% weight): Net defect velocity is our primary metric - defects closed minus defects discovered per sprint, measured over a 6-sprint rolling average. This gives realistic throughput that accounts for defect injection rate. We segment this by severity to ensure we’re not gaming the metric by closing trivial bugs while critical issues pile up.
Tier 2 - Quality Indicators (25% weight): We track severity distribution trends and defect age distribution as quality signals. If critical defects are increasing as a percentage of total backlog, or if average defect age is rising, we apply a risk adjustment factor to our velocity forecast even if raw throughput looks good.
Tier 3 - Leading Indicators (15% weight): Escape rate from previous release and test coverage metrics help us predict future velocity impacts. High escape rates historically correlate with 20-30% velocity drops in subsequent releases as critical bugs disrupt sprint plans.
For KPI weighting in release forecasting, we use the net velocity from Tier 1 as the baseline, then apply multipliers based on Tier 2 and 3 signals. For example, if severity distribution is worsening (more critical defects accumulating), we multiply forecast velocity by 0.85 to account for the complexity drag.
The key insight is that no single metric tells the full story. Burndown is too optimistic, raw throughput ignores quality, and escape rate is too lagging. The composite approach with weighted KPIs gives us forecast accuracy within 15% of actual results, versus 30-40% variance when we used simple burndown charts.
For trend analysis, we’ve found 6-sprint rolling averages balance responsiveness with stability. Shorter windows are too noisy, longer windows hide emerging problems until it’s too late to course-correct.
I’d add escape rate as a leading indicator rather than a core velocity metric. High escape rates usually predict future velocity drops because escaped defects come back as critical bugs that disrupt planned work. We weight escape rate heavily in our quality gates but use throughput for actual capacity planning. The key is separating predictive metrics from capacity metrics in your KPI framework.
We moved away from simple burndown to a composite metric that combines throughput with defect injection rate. Specifically, we track net defect velocity (closed minus newly discovered) per iteration. This gives a more realistic picture of whether you’re actually making progress or just treading water. For dashboard configuration, we display both gross throughput and net velocity side by side so stakeholders can see the full story.
That’s a helpful distinction between predictive and capacity metrics. How do you handle the lag time in escape rate data? By definition, escaped defects aren’t discovered until after release, so it seems like a trailing indicator rather than something you can act on during the current release cycle. Do you use historical escape rates from previous releases as a risk adjustment factor?
We use a weighted scoring model that combines three metrics: 40% throughput (defects closed per sprint), 35% net velocity (closed minus discovered), and 25% quality trend (severity distribution of open defects). The quality trend component helps us catch situations where we’re closing lots of low-severity bugs but accumulating critical issues. For trend analysis, we look at 13-week rolling averages to smooth out sprint-to-sprint noise.