Defect leakage

Defect leakage shows where bugs created during a sprint were found. Choose a closed sprint in the dashboard header to read its saved observation, then select an environment to inspect the issues behind the count.

Fixing a bug does not remove it from its creation period. The metric keeps the furthest confirmed matching environment from before completion and the sprint cutoff.

On the dashboard

The tile shows the leakage share with the unit “to prod”, the change against the previous sprint (for example ”▼ 17 pts”), and a strip of up to six closed sprints ending at the chosen sprint. Lower leakage is green, higher is red, and unchanged or unavailable comparisons stay neutral. The line under it reads “N of M classified bugs reached the last step”.

The Defect leakage section shows “Where bugs were found, by environment”:

Since … and Against …: the change from the first sprint in view and from the sprint before.
… · environment ladder: one bar per environment for the chosen sprint, plus Unclassified.
… · share of classified bugs per environment across the sprints in view.
Bugs created by sprint · total, per environment, Unclassified beside.

The section reads every closed sprint of the chosen sprint’s calendar year, up to that sprint. It says Bugs this year only when the whole year is in view and every observation in it is usable, and … year average only when, in addition, every share is known; otherwise it says Bugs in these sprints and … average. The tile keeps its six-sprint strip.

Selecting an environment bar opens the issue list side panel, headed for example “Bugs found in Production” or “Unclassified bugs”, with the sprint and Defect leakage as chips. Opening a list checks your access again.

Selecting the section title opens Defect leakage details with the full saved observation, the sprint trend and its values table. The sliders button opens Defect leakage settings.

Set up tracking

The guided setup step does this for you; see Guided setup. To change it later:

Open Defect leakage settings, expand Defect tracking settings and choose Load defect settings.
Select the issue types that represent bugs. The board’s projects define the search scope.
Save an environment ladder, ordered from the earliest environment to the last. The last environment is the leakage environment. The env:* label preset uses Development, Staging, and Production.
Select Enable defect tracking. Leave Only bugs assigned to this sprint off to count bugs created in the window regardless of sprint assignment. Turn it on if the cohort should also require sprint membership.

Each team has its own ladder, so one team can call an environment Pre-prod while another calls it Staging. A team that has not saved its own ladder uses the ladder saved for the whole installation before teams had their own, if there is one.

Changing a team’s ladder affects only that team’s future observations. Saved closed observations keep their own rules.

Rules use standard Jira fields. Conditions in one group must all match; any matching group can assign an environment. If several environments match, the furthest one wins. No match stays Unclassified.

Environment history is supported for labels and components. Rules using other fields, such as Environment or Affects Version, cannot establish complete discovery history. The screen explains incomplete evidence rather than treating the current field as proven history.

Check rules before saving

Choose defect types and edit the ladder, then select Check latest 100 bugs. The check applies your unsaved draft to up to 100 most recently created bugs visible to you in the board’s projects.

It includes fixed bugs and ignores sprint membership. It shows classified and Unclassified counts and percentages, plus counts for each environment. An empty sample has no percentage.

This checks the current Jira fields, not the environment in which a bug was originally found. It does not save rules, collect historical evidence or change metric observations. Editing the draft clears the result; check again before relying on it. Jira search can lag recent changes.

If no rule matches, use agreed labels such as env:dev, env:stage and env:prod with the label preset and the same values in Jira Automation. Missing fields remain Unclassified.

How the numbers are calculated

The creation window starts at the sprint’s start time and ends at its actual close time. A saved observation includes the bugs found by the completed search within the configured projects and types. Unknown creation times and unknown scope are shown separately.

Leakage: bugs assigned to the last environment divided by classified bugs.
Classification coverage: classified bugs divided by all bugs known to be in the creation window.
Environment distribution: bugs in an environment divided by all bugs known to be in the window, including Unclassified.

For example, 5 reported bugs include 2 in Staging, 2 in Production, and 1 Unclassified. Leakage is 2/4 = 50%. Classification coverage is 4/5 = 80%. Production represents 2/5 = 40% of all reported bugs.

Each bug belongs to one environment. Unclassified stays visible and is excluded from the leakage denominator. A missing or unverified denominator produces an explanation, not a zero.

Why fixed bugs remain counted

Completion requires both a Done status category and a resolution. The collection checks confirmed field history while the bug was unfinished, up to the observation cutoff.

Recorded history	Environment retained
Production, then Staging, then fixed	Production
Staging, then fixed, then moved to Production for verification	Staging
Staging, then fixed, then reopened with Production before the cutoff	Production
Staging before sprint close, Production only after close	Staging in the closed observation

These are confirmed field values. They do not prove why someone changed a field or where the underlying cause originated.

Incomplete history may hide a higher environment. The screen names that limitation. A previously saved observation is not silently rewritten when an issue is fixed or its fields change later.

Details panel and gadget

In Defect leakage details, the selected closed observation opens automatically. Count shows issue counts; Percent shows the distribution using all bugs in the window. Select an environment or Unclassified to open its saved issue list.

Sprint trend in the details panel shows up to 12 closed sprints. In Count mode it has Total reported, each saved environment, and Unclassified as separate series. Percent mode shows the leakage ratio among classified bugs. The values table gives exact counts, quality, and collection time.

A missing observation is a gap. Changes to the saved rules, scope, or collection method break the series. The chart does not join incompatible periods or turn missing data into zero.

The compact gadget shows one selected result or sprint trend at a time. Its leakage headline uses classified bugs; environment bars use all known in-window bugs. Quality, Unknown counts and saved collection time stay visible.

Expand How we count and saved evidence for collection and discovery details. The trend has a period inspector instead of a full history table.

Open defect details opens the QA Metrics page with Defect leakage details at the same team, sprint, view and units. Choose an environment or Unclassified there for the full saved issue list; opening a list performs a fresh permission check.

In the details panel, explicit view and unit choices survive later sprint navigation, while a new entry can bring new display defaults. The gadget never starts collection or saves these local choices as team preferences.

In gadget configuration, set the title, team, sprint, default view, and units. The sprint selector changes the displayed period. Reloading reads saved observations; rendering the chart does not collect issue history.

Missing history on the tile and section

Missing observations keep their positions. A line joins adjacent points only when their saved evidence supports comparison. A zero leakage percentage is a real value; no classified bugs is an unavailable percentage.

The charts describe saved observed cohorts, with their existing historical-scope limitations, and never fill missing history. History can be unavailable while the freshly checked selected result stays readable; the section then shows only the chosen sprint with the reason. A percentage is never calculated from only the readable part of a cohort.

Change from the preceding sprint

The change is expressed in percentage points and shown as whole points: ”▼ 17 pts” on the tile, “down 17 points” in the section’s Since … and Against … cards. It compares the selected saved cohort with the immediately preceding closed sprint in the view.

For example, 2/4 = 50% followed by 1/3 is a change of −16.7 percentage points, shown as ”▼ 17 pts”. The calculation uses the fractions before rounding, so it does not subtract the displayed 50% and 33%.

A numeric change requires matching saved scope, settings, ladder, and collection method; valid, nonoverlapping sprint windows; completed searches; and no unknown creation window or scope. Both classified denominators must be positive. Discovery history must be complete for every included bug, including Unclassified.

The comparison must also match the observation on screen. If a separately read current result has different saved identity, settings, counts or evidence, the change is withheld until the observation is reloaded.

Otherwise the screen explains why comparison is unavailable. It does not skip a missing preceding observation to find an older number. Legacy observations without discovery evidence can still be read, but do not qualify for this comparison.

This change describes the saved observed cohorts. It does not establish the complete historical project/type population or explain the cause of a change. The Partial label remains visible.

Understand quality and missing data

The search uses the projects, issue types, and visibility available when collection runs. It cannot prove that today’s search finds every issue that historically belonged to those projects and types.

A closed observation is Complete only when the search finished with no unresolved scope, every retained bug is classified and every environment history is complete; otherwise it is Partial. Even a Complete observation keeps the note “historical cohort scope unverified”.

The screen shows the sprint close time, collection time, and collection delay. Recent Jira updates may still be waiting for indexing. Completed search, complete environment history, and complete historical scope are different claims.

Older saved observations keep their original calculation and evidence. When discovery history was not collected, the screen explains that counts use fields observed after close. Incomplete collections, unclassified bugs, and unreadable facts are shown explicitly.

Tracking must be enabled while the sprint is open to save a closed observation. Older unobserved sprints are not collected retrospectively. Loading a closed sprint with no saved observation explains that absence.

Issue lists use the saved members. Access is checked again when you read them. If any retained member cannot be authorized, the aggregate and list are withheld rather than revealing a partial count.

Check a number manually

Note the saved window, projects, issue types, membership option, and ladder.
Identify the bugs created in that window. Include fixed bugs.
For each issue, follow its confirmed label/component history while unfinished, before the cutoff. Assign its furthest matching environment, or Unclassified.
Count the last environment and divide by all classified bugs. Check classification coverage separately.
Compare the issue keys with the app’s environment lists, keeping the saved search and historical-scope limitations in mind.

Jira has no built-in defect-leakage report. A current Jira search may differ from a saved observation after project, type, visibility, or membership changes. The saved collection time and evidence explain which population the chart describes.