Deploy free

Bug rate: read the ratio, not the bar

The Bug Rate widget plots newly-opened bugs against everything else your team opened that week, side by side, bar by bar. The height tells you volume. The ratio between the two bars tells you whether you're building or firefighting — and that's the number that actually matters.

deckgauge · Board · Intelligence
BugsOther

Six weeks of bugs (rose) vs other work (grey), opened counts.

What it measures, and where the data comes from

Every issue opened in the window gets bucketed by week and split two ways: bug, or not-bug. No severity, no priority weighting — just a plain count of "did this open as a bug" against "did this open as anything else."

  • Jira — uses the native issue_type field. Anything typed Bug counts as a bug; Story, Task, Epic, and the rest count as other.
  • Azure DevOps — same idea, off the work item's work_item_type. A Bug work item counts as a bug; User Story, Task, Feature land in other.
  • GitHub — GitHub issues have no native type field, so this one's a label heuristic: any issue carrying a label containing "bug" or "defect" counts as a bug. If your repos don't label bugs consistently, this leg will undercount — that's a labeling-hygiene problem worth fixing on its own, not a widget bug.
Volume, not severityA typo fix and a data-loss incident both count as one bug each. Pair this widget with your severity/priority field if you need to know whether the bugs piling up are scary or trivial.

How to read it

Don't eyeball the rose bar in isolation — a tall bug bar in a week where everyone shipped a ton of other work is normal. Eyeball the gap between the two bars instead. A wide gap (grey towering over rose) is a team building. A narrow gap, or rose catching up to grey, is a team defending what it already shipped.

Watch for two shapes specifically: a step change right after a release date — bugs jump and don't come back down — and a slow convergence where the two bars creep toward each other over a month or two. The step change tells you what happened. The convergence tells you something structural is wrong.

What it tells you over time

One week's ratio is noise. Four to six weeks of ratio is a story. If the rose bar's share of the total is climbing release over release, your team isn't getting less careful — your codebase is getting harder to change without breaking something. That's a design and test-coverage problem, and it compounds: today's bug count is next quarter's velocity tax.

Example situations

1. A release shipped with quality debt

deckgauge · Bug Rate
BugsOther

Launch at week 4 — bugs jump and stay up.

What you're seeing: three quiet weeks, then a launch, then the rose bar roughly triples and never drops back to baseline. That's not a bad week — that's the launch's real cost showing up two weeks late.

How to react: don't quietly reassign people to "just fix bugs" and pretend it's not a plan. Name it: this sprint is a stabilisation sprint, on purpose, because of what shipped. Check it against Rework Rate — if churn on the same files is also up, you know exactly which corner got cut.

Managerial playPut a planned stabilisation window on the calendar after every major launch, before you need it — it's cheaper to schedule than to defend after the fact. Run a blameless retro on what broke and why, not who broke it. And rebalance what you praise in standup: "finished and stable" should get louder applause than "started something new," or you'll get more launches and more of this exact chart.

2. Bug bars rivaling the rest, week after week

deckgauge · Bug Rate
BugsOther

No launch, no incident — just a flat, tight ratio for six weeks straight.

What you're seeing: no spike, no story — just rose sitting almost as tall as grey, every single week. There's no single villain here. This is steady-state. The team has quietly become a bug-fixing team that also does some feature work, instead of the other way round.

How to react: this doesn't get solved with a sprint of heroics; it gets solved by refusing to load the sprint the same way next time. Look at Ticket Coverage Rate and Investment Allocation alongside this one — if untracked hotfixes are sneaking in outside planning, that's your leak.

Managerial playSet a fixed quality budget per sprint — a capped number of bug-fix points — and hold planning to it instead of letting bugs silently eat whatever capacity shows up. Stop over-committing the sprint on the feature side; a team firefighting at 90% capacity has no slack left to actually fix root causes. And spend real engineering time writing tests for the two or three files where bugs keep clustering — that's usually where the actual leverage is, not in a general "write more tests" mandate.

Frequently asked

What is bug rate and how is it calculated?
Bug Rate plots newly-opened bugs against everything else opened in the same week, bar by bar. The important figure is the ratio between the two bars, not the height of either.
Why read the ratio instead of the number of bugs?
Because raw bug counts scale with how much you shipped. A busy week produces more bugs in absolute terms without the team getting worse. The ratio tells you whether you are building or firefighting.
What does a rising bug ratio actually mean?
That a growing share of intake is corrective rather than new work. Sustained over several weeks it usually points at quality debt in a specific area rather than a general decline in care.

Related widgets

Last updated