Deploy free

Ticket coverage rate: PR-to-ticket traceability, in one number

Ticket Coverage Rate is the percentage of merged pull requests that link to at least one tracking ticket, plotted as an 8-week sparkline against a benchmark tier. It's the closest thing you have to real PR-to-ticket traceability — an audit trail for "why did this code change?" — and it's usually lower than people assume.

deckgauge · Board · Intelligence
Ticket coverage
88%
Elite

Ticket coverage rate, healthy tier.

What it measures, and where the data comes from

One ratio: of every pull request that merged in the window, what share reference at least one ticket — a Jira key in the title or description, a GitHub/GitLab issue link, or an Azure Boards work-item link. A PR needs exactly one recognized link to count; ten links don't score it higher than one.

  • GitHub — pull requests, matched against linked issues and Jira keys found in the title or description.
  • GitLab — merge requests, matched against linked issues and Jira keys the same way.
  • Azure DevOps — pull requests, matched against linked work items and Jira keys, from the repos you've opted into code intel for.

The 8-week sparkline gives you trend alongside the current number, and the tier badge tells you where that number sits against the benchmark: Elite at 80% or higher, High at 60%, Medium at 40%. Below Medium is Low.

How to read it

Read the tier before the percentage. An 88% in the Elite band means the exceptions — the untracked 12% — are probably legitimate: a typo fix, a config tweak, a hotfix pushed before there was time to open a ticket. That's normal and healthy; don't chase 100%.

A number sitting in Medium or Low is a different story. That's not "a few PRs slipped through," that's a meaningful share of your delivered work with no record of what problem it solved or who asked for it. Six months from now, nobody — including the author — will remember why that PR exists.

What it tells you over time

The sparkline matters more than any single week's number. A steady climb usually means a process change stuck — a PR template field, a merge check, a habit. A steady decline is worth investigating immediately: something is making linking harder, or someone decided it wasn't worth the friction.

Watch it against PR volume too. Coverage and volume moving in opposite directions — more PRs, less linking — is the tell that people are taking shortcuts to hit a date, not that the process broke on its own.

Example situations

1. Coverage sits below the High band

deckgauge · Ticket Coverage Rate
Ticket coverage
54%
Low

Coverage stuck in Low, flat for weeks.

What you're seeing: just over half of merged PRs link to a ticket, and it's been sitting there for two months — this isn't a bad week, it's the baseline. Nearly half of what shipped has no recorded reason attached to it.

How to react: this is your audit and traceability gap, and it will bite you the first time someone asks "why do we have this code" during a security review, a compliance pass, or just onboarding a new hire. Don't turn this into a shaming exercise in standup — that just teaches people to fake a ticket number to get past you.

Managerial playFix the friction, not the people. Add a required ticket-reference field to the PR template so linking is the default path, not an extra step someone has to remember. If your tool supports it, block merge on a missing link for anything above trivial size (exempt one-liners and hotfixes explicitly, so the rule doesn't get gamed). Re-check in three weeks — a template change should move this number fast if the gap was habit, not tooling.

2. Coverage falling while PR volume rises

deckgauge · Ticket Coverage Rate
Ticket coverage
61%
Medium

Coverage sliding as merge volume climbs — quick fixes going untracked.

What you're seeing: coverage has dropped from Elite territory to Medium over eight weeks, and it happened during a stretch where merge volume went up, not down. More is shipping, and a shrinking share of it is tracked.

How to react: this pattern is almost always scope creep hiding in "quick fixes" — small changes that felt too minor to justify opening a ticket, until there were enough of them to move a real number. The risk isn't any single untracked PR; it's that nobody can now say what the team actually built this quarter.

Managerial playDon't add a heavyweight ticket process for small work — that just pushes people back to skipping it. Give the team a lightweight ticket type (a one-line "quick fix" issue, no story points, no sprint assignment) so logging takes seconds, not a planning-meeting slot. The goal is visibility into what's happening, not bureaucracy around it. Pair this with Investment Allocation to see whether that untracked volume is bug fixes, tech debt, or something else entirely.

Frequently asked

What is ticket coverage rate?
The percentage of merged pull requests that link to at least one tracking ticket, shown as an eight-week sparkline against a benchmark tier. It is the closest available measure of pull-request-to-ticket traceability.
Why does PR-to-ticket traceability matter?
It is the audit trail for why a code change exists. Without it, questions about the origin of a change — for compliance, capitalisation, or a post-incident review — cannot be answered from the repository alone.
What does a falling coverage rate indicate?
Untracked work creeping in: changes being made outside the planning process. It is usually a symptom of process friction rather than deliberate avoidance.

Related widgets

  • Bug Rate — untracked "quick fixes" often turn out to be undocumented bug fixes; check this alongside a coverage dip.
  • Investment Allocation — once coverage improves, this shows what the newly-tracked work actually was.
  • DORA Metrics — traceability gaps often sit next to the same process gaps that drag down lead time and change failure rate.
  • Back to the widget reference.

Last updated