Bug fix rate

Bug fix rate is the share of reported bugs that an engineering team resolves within a given period, usually expressed as a percentage of all open or incoming defects. If 80 bugs are reported in a sprint and the team closes 60 of them, the bug fix rate is 75 percent. The metric is a simple ratio, but it answers a sharp question: is the team keeping up with the defects arriving in the backlog?

A rate above 100 percent means the team is closing more bugs than are coming in, so the backlog is shrinking. A rate below 100 percent means defects are piling up faster than they are resolved. Tracked over several sprints, bug fix rate shows the trend in software quality and the load on the engineering team more honestly than a raw count of fixes ever could.

The core formula divides bugs resolved by bugs reported over the same window, then multiplies by 100. The window matters: a weekly rate is noisy, a quarterly rate is stable but slow to react. Most teams settle on the sprint or the calendar month so the number lines up with how they already plan work.

The inputs sound obvious, but each one hides a decision. Be explicit about what counts as a bug, when a fix counts as resolved, and whether you measure against incoming defects or the total open backlog.

1. 1

   Bugs reported

   Count every defect logged during the period. Exclude feature requests, duplicates, and items closed as "works as designed" so the denominator reflects real defects.

2. 2

   Bugs resolved

   Count defects that were closed and verified during the period, even if some were reported in an earlier window.

3. 3

   Period length

   Fix the window to a sprint or a month so the rate is comparable across time. Mixing window lengths makes the trend meaningless.

4. 4

   Resolution definition

   Decide whether resolved means merged, deployed, or verified in production, and apply the same rule every period.

A single bug fix rate number tells you the team is falling behind, but not why. A metric tree decomposes the rate into the drivers that actually move it, so you can see whether the problem is inflow, capacity, or the time each fix takes. The headline number sits at the top, and the causal levers sit beneath it.

When the rate drops, the tree lets you trace the cause to a specific branch. A spike in incoming defects is a quality problem upstream. A rise in fix time is a debugging or review bottleneck. Each branch points to a different team and a different intervention.

There is no universal target, because the right rate depends on inflow, severity mix, and product maturity. As a rule of thumb, a sustained rate at or above 100 percent means the backlog is stable or shrinking, which is the floor a mature team should hold. The ranges below give a practical starting point for a sprint-level rate measured against incoming defects.

Improving bug fix rate is rarely about working harder on fixes. It is usually about reducing inflow, removing bottlenecks in the path to resolved, and protecting fix capacity from being crowded out by feature work. The levers below target the branches of the tree rather than the headline number.

1. 1

   Counting unverified fixes

   Marking a bug resolved before the fix is verified inflates the rate and hides regressions when the bug reopens.

2. 2

   Mixing severities

   Treating a cosmetic typo and a payment outage as equal hides whether the team is fixing the bugs that actually matter.

3. 3

   Ignoring the backlog

   A rate near 100 percent can still sit on top of a huge ageing backlog. Track open defect count and ageing alongside the rate.

4. 4

   Gaming the denominator

   Closing real defects as duplicates or "works as designed" lifts the rate on paper while the problem stays in production.