"Bug Links" Is Not "Bugs"

The sprint trend moved from 102 to 103.

One new bug this week, then. That is how the line was read in the review, and it is the only way that line can be read.

The snapshot behind it holds 103 link references against 76 unique bug keys.

Two Populations, One Number

Those are not the same quantity and the difference is not small. Twenty-seven of the references are second, third and fourth links to a bug that was already counted.

A bug that touches one story contributes one. A bug that touches four stories contributes four. The counter is doing exactly what it was built to do — it counts rows in a link table — and the label on the chart says "linked bugs (total)," which most people read as "bugs."

So the metric measures how widely defects were linked, and is reported as how many defects exist.

The Metric Rewards Exactly the Wrong Thing

Now look at what that does to the week in question.

The most informative defect of the sprint was a single fault in discount handling that reached four sibling stories. One root cause, one fix, four stories affected. It contributed four to the counter.

A narrow bug, local to one story, easy to fix, low consequence, contributed one.

The defect that matters most is the one the number exaggerates most. That is not a rounding problem or a data quality problem. It is the metric running backwards: a count meant to size the defect load instead scores each defect by how many places it spread to, and then presents the result as a headcount.

If you wanted to design a number that made your worst week look like four ordinary ones, this is the number.

Why 102 to 103 Told You Nothing

Follow the movement through and it gets worse.

A trend of plus one, on a counter of links, is consistent with several different weeks. One new story-local bug. One new shared defect that has so far been linked to one story and will pick up three more links next week when someone tidies the board. Or nothing new at all — an existing bug linked to one additional story during triage.

Three very different weeks, one identical number.

And the third case is the one to sit with. A link added during housekeeping, to a defect raised a fortnight ago, moves the same line by the same amount as a fresh production-affecting fault. The metric cannot distinguish new information from re-filing.

Publish Both, and Publish the Spread

The fix is not to switch to unique keys and move on. Both numbers are worth having.

Unique keys tell you how many distinct defects exist — the real work item count, the thing you resource against. Link references tell you how much story surface those defects touch, which is a genuine signal about blast radius and about how much retesting is implied.

The interesting quantity is the relationship between them. 103 against 76 is roughly 1.36 references per defect. On its own that is trivia. Tracked over several sprints it is one of the few numbers on a QA dashboard that tells you something you cannot see by reading tickets.

A widening spread means defects are moving from story-local to shared-component. Same defect count, more stories touched each — that is the fault line shifting from feature work into shared logic, and it is the shift a Test Lead most needs to see early, because it changes what regression has to cover and it changes how much a single fix can break.

A single total hides it completely. Both numbers can rise, both can fall, and the ratio moves independently of either.

Put the Unit in the Name

Here is the rule, and it costs nothing to apply.

State the unit of every metric you publish, in the name of the metric, not in the documentation. "Bug links (references)" and "Bugs (unique keys)" are two labels that no one can misread. "Linked bugs (total)" is one label that nobody can read correctly.

A metric name is not a title. It is the only part of a metric most readers will ever see, and it will be quoted back to you in a steering meeting by someone who was never going to open the query behind it.

• Name the thing being counted, not the thing being discussed. Rows in a link table are references. Issues are keys. Test executions are runs, not tests. Where the counted unit and the discussed concept have different names, the counted one goes in the label.
• Publish the denominator next to the numerator whenever a many-to-one relationship exists. Bugs to stories, executions to cases, failures to environments. If one row of the underlying data can map to several rows of another, both counts belong on the chart and the gap between them is content, not clutter.

Two rules, and between them they would have turned that review from a discussion of one new bug into a discussion of a shared fault in discount handling that had reached four stories.

Why This Survives So Long

The counter is correct. That is what protects it.

Nobody built this to mislead. Somebody needed a defect number for a sprint report, the link table was where the relationship between bugs and stories already lived, and counting rows in it was the query that took five minutes instead of an afternoon. It has been right ever since, in the narrow sense of returning what it says it returns.

Then it becomes furniture. It appears on the same slide every sprint, the line goes up and down, people develop a feel for what normal looks like, and the feel is built on a unit nobody ever named out loud.

The moment worth catching is the first time someone says the number in a sentence. "One new bug this week." That sentence is a translation, and every translation of a metric into English is where the unit gets dropped — which makes it the cheapest place to notice that the unit was never there.

Take the last quality number you presented. What exactly is one row in the query behind it — and does the label say so?