Back to Defect metrics
🐛 Defect

Defect severity distribution

How your defects break down by severity level — the signal that distinguishes a manageable bug queue from a crisis.

defectseverityclassification

// Formula

count per severity÷total

// About this metric

Defect severity distribution shows what proportion of your defect backlog falls into each severity tier — critical, major, minor, and trivial. Unlike a single-number metric, this distribution reveals the shape of your quality problem: many small issues is a qualitatively different situation from a few showstoppers.

Severity classifications are team-defined, which makes cross-team comparison unreliable. But within a team, the distribution trend over time is highly informative. A shift towards higher proportions of critical and major defects warrants investigation: it could mean quality is degrading, testing is finding more serious issues (which could be positive), or defect triage standards are changing.

The distribution is also an input to release-readiness decisions. Most teams block releases on open critical defects regardless of count; the question is how many majors are acceptable. Tracking distribution helps calibrate that decision with data rather than gut feel.

Because classification is subjective, the distribution is classed here as a qualitative benchmark rather than a numeric one. The signal is the trend and the relative balance between tiers, not the absolute percentages.

// Calculator

🧮 Calculator — severity distribution

Total defects50
16%
50%
30%
Critical: 4%
Major: 16%
Minor: 50%
Trivial: 30%
Critical defects at 4% — within the healthy threshold (under 5%).

// When this is healthy

A healthy distribution skews toward minor and trivial severities, with critical defects making up under 5% of the total. A sudden rise in critical or major severity is the signal, not the absolute percentages.

// Why no numeric benchmark

Severity classifications vary so much between teams that published benchmarks would be misleading. One team's "major" is another team's "minor".

// When to use this metric

Use severity distribution as a release-readiness input and quality trend indicator. Review the distribution at each sprint review or release candidate to catch severity drift early.

It is most valuable when the classification scheme is stable and consistently applied. If you change severity definitions, note the date — it will create an apparent step-change in the distribution that doesn't reflect actual quality change.

// Common pitfall

Under pressure to release, critical defects have a way of becoming majors, and majors have a way of becoming minors. "Severity inflation" — where thresholds shift over time to make the distribution look better — is one of the most common ways this metric is corrupted. Anchor severity definitions to user impact (data loss, service outage) rather than engineering judgement, and review classifications in retrospectives.