Reopened tasks

Count the issues of your chosen types that came back to a Reopen or Returned status during a sprint, each issue once. For example, 4 returned issues among 20 eligible issues is 20%.

The dashboard section calls this metric Reopen rate; guided setup and the Jira gadget call it Reopened tasks. The metric is optional and off by default. Anyone who can see the team’s board can configure and collect it; a result is readable only when they can access every required issue.

On the dashboard

The tile shows “N of M” with the share and the change against the previous sprint. For up to 40 issues it draws one square per issue of the denominator with the N returned issues marked; above 40 it draws a bar.

The Reopen rate section shows “Issues that came back after being called done”:

• … · each square is one issue in the sprint: one square per issue of the denominator for the chosen sprint (up to 240 issues), with the returned issues marked.
• Top 3 by confirmed returns: the issues that came back most often, with links to Jira.
• Trend by sprint · issues that came back (Count) or Trend by sprint · share of issues that came back (Percent). Selecting a column chooses that sprint.

The squares and the share use the same denominator as the tile: every selected issue that belonged to the sprint, whether or not it was done. See How the count works.

Selecting the section title opens Reopen rate details with the saved result, the counted issues and Selected sprint / Sprint trend. The sliders button opens Reopen rate settings.

Set up and collect

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

1. Open Reopen rate settings, expand Reopen settings and choose Load Reopen settings.
2. Select Show Reopen metric, the issue types to count (Task types to count), and the workflow statuses that mean Reopen or Returned (Statuses that mean Reopen). Select actual sub-task types if your team returns development or testing sub-tasks while the parent story stays In Progress.
3. Choose Save Reopen settings. In Reopen rate details, for a closed sprint, select Collect Reopen. Collection runs in the background. Reload Reopen reads its saved result; it does not start another collection.
4. Use Count or Percent to change the display. This does not collect or reload data.
5. Select Show counted tasks to see issue links, the number of confirmed returns and their first and last times. Each issue adds one to the headline, however often it returned.

Teams without an explicit Reopen status can leave the metric hidden. Turning it off and saving hides the count and the issue list. Your selected types and statuses are kept unless you clear them. A changed configuration requires a new collection before an older result can be shown again.

Add it to a Jira dashboard

Add QA Metrics — Reopened tasks from Jira’s gadget catalogue. In Edit, choose the team, closed sprint and your preferred title, then save.

The gadget reads saved results and cannot start collection; use Reopen rate details on the QA Metrics page for that. It shows confirmed counts and their issue details. Its Count and Percent controls behave like the page; Percent shows the percentage and its quality, or explains why it is unavailable. Select Sprint trend to compare saved observations.

You can inspect another available closed sprint inside the gadget and return to its configured sprint. Editing and saving changes the configured default. A refresh checks access again.

When the metric is off for the team, the gadget’s contents are hidden; the gadget itself can be removed through Jira’s menu.

How the count works

Count distinct selected issues entering the configured Reopen status set from outside that set during the sprint, including both time boundaries. Done and resolution are not required.

Moving between two selected Reopen statuses does not add a return. Closing a task later does not erase its earlier confirmed return. Status names are never guessed or matched automatically.

Task type and sprint membership are evaluated at the transition time. An actual subtask uses its historical parent’s sprint membership. An ordinary related task uses its own membership; a link to a story does not place it in that story’s sprint. Two selected subtasks entering Reopen count as two even when the parent story stays In Progress.

For example, a development subtask enters Reopen under a parent in the sprint, then moves to a parent outside the sprint and enters Reopen again. Moving it back before the sprint closes does not make the second return eligible. The headline is 1 issue, and its detail shows 1 confirmed return, at the time of the first event.

Issues returned most often

The dashboard section shows Top 3 by confirmed returns directly. In Reopen rate details and in the gadget, choose Show top 3 returned tasks.

For the selected sprint and saved observation, the list shows up to three issues with the most confirmed returns, with links to Jira. Equal counts use issue ID order. This ranks the entire saved counted set, not the first page of the issue list.

An issue returned five times still adds only one to the headline and percentage. Closing it later does not erase those returns. Partial observations explicitly rank only known confirmed returns; missing history or issues may change the order. There are no rankings of people.

Older observations may have no saved ranking. Their count and details stay available; collect again to create a new observation with ranking data. Previous observations are not rewritten.

Rankings require the same access to all saved candidates and their dependencies as the headline. Reloading or changing the sprint clears old results.

Read the result

Complete means the closed sprint started under observation and its existing sprint composition has complete quality for the same saved window, with no unresolved task evidence.

That composition is the one saved by sprint commitments (say/do); Complete depends on that matching composition as well as Reopen history, not only on finishing a Jira search.

Partial means some matching tasks or returns may be missing. Missing or inconsistent history, an unknown historical parent or a type conversion can prevent a transition from being confirmed.

A scope change at the exact return time remains ambiguous. Today’s parent or Sprint field is not substituted for missing historical evidence.

The collection time identifies when the saved observation was produced. Reopening the page reads that observation. An explicit new collection creates a new one.

If sprint dates change, the result must be collected again; when an original recorded start exists it is kept and explained on the card. An unobserved sprint start is also shown explicitly.

Not shown means the result could not be safely loaded or access to all required issues could not be confirmed. It is not zero. Access is checked again for each count and issue-list request.

The agreed percentage is distinct returned tasks divided by all distinct selected-type tasks that belonged to the sprint during its window. For example, 4 returned issues among 20 eligible issues means 20%, even if only 10 issues were closed.

Type and membership must overlap in time; an actual subtask uses its historical parent’s membership. Issues without returns also belong in this denominator. Counting the same issue several times does not increase either total.

For new collections, Percent follows three cases:

• Complete: the sprint started under observation, its matching saved sprint composition is complete, and task types, membership and return histories are known. For 4 of 20 tasks, the display is 20% · Complete.
• Partial: membership was reconstructed by a finished search. The same 4 of 20 gives 20% · Partial, with a warning that missing tasks may make the denominator too small. This is an estimate over the reconstructed cohort. An active window or a closed window without complete saved composition also remains Partial.
• Unavailable: conflicting membership/type evidence, unknown eligible tasks, incomplete return histories or changed sprint dates prevent a trustworthy rate. The confirmed count remains visible with the reason. Missing data is never displayed as 0%.

Zero returns among 20 known eligible tasks is 0%. No eligible tasks means there is no percentage to calculate. All current access checks apply to the denominator as well as returned tasks; inaccessible results expose neither number.

Older observations keep their previous unavailable percentage until you explicitly collect again. A new collection creates a new observation and keeps prior records.

If the complete sprint composition used by an observation is revised, the metric asks for a new collection instead of continuing to label the old result complete. This does not rewrite earlier observations.

Ignore the Automation actor

In Reopen settings, optionally enable Ignore transitions by the Automation for Jira actor. It is off by default. Save and collect again to apply the changed rule.

Only transitions attributed to the verified built-in Automation app account are excluded. Rules configured to act as a person remain counted. Other apps, missing authors and unverified actor evidence remain unknown; relevant unknown transitions make the result Partial and the percentage unavailable.

The metric shows a note when its saved observation uses this exclusion. The same rule applies to the headline and to the first and last returns in the counted-task list.

Excluded returns do not remove an otherwise eligible task from the percentage denominator. Older observations keep their original settings and evidence. No personal identities are stored, and there are no metrics by person.

Sprint trend and change from the previous sprint

The dashboard section shows the chosen sprint and its trend side by side. Reopen rate details and the gadget offer Selected sprint and Sprint trend.

The trend in the details panel reads up to 12 saved closed-sprint observations ending at the selected sprint. Count shows returned issues; Percent shows the qualified percentage. The table shows each observation’s quality and collection time. Open a sprint from the table to inspect its saved result and counted issues.

The change below the headline uses the immediately preceding closed sprint. In Count, this is the difference in returned issues; in Percent, it is the difference in percentage points.

For example, 20% after 10% is a change of 10 percentage points; the dashboard shows it as ”▲ 10 pts”. Comparisons involving partial data are labelled Partial and can be affected by missing historical issues.

A missing or unreadable preceding observation makes the change unavailable: the app does not skip back to an older result. An empty denominator has no percentage and never becomes 0%.

Missing observations and changes to counting rules or project scope break the trend line. Reconstructed observations use hollow points. Trend reads do not collect changelogs or start background reconstruction; select a sprint and use Collect Reopen when a saved observation is missing.

If an issue changes type, the type at each return matters. A round trip back to the same observed type can establish that type’s earlier kind.

A different historical type whose ordinary/subtask kind is not established remains unknown; the metric may show a partial count and explain why its percentage is unavailable.