Epic progress

See known completed work for the epics your team follows, with its collection time and data quality. For example, 5 completed issues out of 10 gives 50% when the full scope and outcomes are verified. Adding 5 incomplete issues changes that to 5 out of 15, or 33%.

Epic progress offers current progress, saved observations by sprint, sprint trends, and a calendar of epics closed during a year. The page and the Jira dashboard gadget use the same counting rules.

On the dashboard

The tile shows how many followed epics are “in flight”, how many stalled, and a bar for each of the first four epics. A bar is filled only where the epic’s percentage is known.

The Epic progress section shows “Epics this team follows, as saved at each sprint close”. It has three parts:

• … · where each epic stands: one row per epic for the sprint chosen in the header.
• Burn-up by sprint · percent done, one line per epic.
• Closed this year · one point per epic on its closing date.

Count / Percent switches the units. The How we count caption explains the rules: finished epics leave the burn-up and appear on the year line.

Selecting the section title opens Epic progress details. It starts without epics; add an epic key (for example one of the followed epics) to get the views Overview, Now, Selected sprint, Sprint trend, Selected epics trend and Closed by year. The sliders button opens Epic progress settings.

Choose epics and enable tracking

The team’s followed epics come from the guided setup step Which epics do you follow? (see Guided setup). The dashboard section shows them automatically.

To look at other epics, open Epic progress details, enter an epic key and choose Add epic to view. You can add up to 5 epics. Adding another opens Overview, which keeps their cards separate because their scopes may overlap.

This selection lasts until reload or a team change. Remove from view removes a selection; it does not disable tracking.

Epic progress settings says “Select an epic to change its tracking and counting settings.” To change them, add the epic in Epic progress details, choose Now and open Epic settings. Anyone who can see the team’s board can enable tracking, include sub-tasks, confirm an existing numeric story-point field, and choose resolutions that mean cancellation.

The app creates no Jira fields or resolutions. Sub-tasks are excluded by default. Enabling tracking or saving settings requests a background collection.

The scope contains direct children of the selected parent. With sub-tasks enabled, it also includes sub-tasks of those children. Other hierarchy levels are not recursively expanded.

Eligible roots use Jira’s hierarchy level, not translated issue-type names. Children are selected by their parent relationship, whatever project they are in.

What the numbers mean

An included issue is completed only when its status category is Done and it has a resolution. A selected cancellation resolution removes the issue from both completed work and scope. Completion percentage is completed included issues divided by all included issues.

The headline shows known completed issues and known issues in scope, with a Complete or Partial label. Known counts do not establish the full scope. When scope or outcomes cannot be verified, the percentage is unavailable, with an explanation. An empty scope also has no percentage.

A percentage is shown only when the collection read every page of the epic’s issues and you pass a fresh access check on the epic and on every saved child. The check includes cancelled work and excluded sub-tasks, before they are left out of the count.

If any child is not visible to you, the epic is not shown to you at all: there is no percentage, no smaller subtotal of the issues you can see, and the epic is not counted as in flight. The section says how many followed epics are not shown, for example “1 followed epic is not shown: some of its issues are not visible to you.” The section text “No percentage: not every child is visible to you.” appears in a different case: the epic is visible, but the collection did not read every page or some outcomes are unknown.

Observations saved earlier get their percentage when they recorded that every page was read and you pass the same access check. Observations without that record stay Partial.

Use Count or Percent on each summary card, including Now, Selected sprint, and Overview in the details panel and the gadget. Count is the default. Percent keeps the known counts beside the verified percentage or its unavailable reason.

Switching units does not collect data or change the counting settings. The selection lasts while that card remains open.

Done without resolution and unknown outcomes have separate counts; neither is counted as completed. The card also names excluded cancellations and sub-tasks.

With story points configured, the card shows known completed points, known points in scope, issues without estimates, and unknown estimates. An empty estimate is different from an unreadable estimate. Unavailable point subtotals are labelled explicitly.

An unestimated percentage appears only with an established denominator; values above 30% are highlighted.

Current and saved observations

In Epic progress details, Now reads the latest saved current collection. Its timestamp is independent of the sprint chosen in the header. Check saved progress rereads saved data and permissions.

Refresh from Jira, available to anyone who can see the team’s board, requests a new background collection. Repeated clicks join an existing pending request. Check saved progress afterwards for the new collection time; a queued request does not mean collection has finished.

Choose a closed sprint, then Selected sprint, to read its retained observation. Tracking must have been enabled for capture. Sprint close starts a background collection, so the panel shows the close time, collection time, and delay separately.

This is an observation collected after close; the exact state at the close instant is unverified. Later issue or settings edits do not replace a published observation. Its original counting settings still apply.

Missing historical observations remain gaps. A pending collection is shown as preparing. Neither means zero, and neither is reconstructed from today’s Jira.

Disabling tracking hides current and historical results without deleting saved observations. Capture of a sprint shared across several origin boards is not supported.

Completed-work change and observed scope

The selected sprint compares with the preceding visible closed sprint. Now compares its saved collection with the latest visible closed sprint in the loaded board window. The heading names that baseline. If it has no usable observation, the app explains the gap instead of silently choosing an older one. The comparison is available on the page and gadget.

Completed-work change and added/removed scope are separate. For example, 3 completed issues becoming 2 is a change of −1 even if no issue was added or removed. Adding an already completed issue can increase both completed work and scope. These are differences between saved states, not counts of transitions into Done or proof of everything that happened during a sprint.

An observed comparison requires compatible counting settings, known inclusion decisions, confirmed completion of member enumeration, ordered collection windows, and access to both sets of issues. For Now, collection must start after the baseline was collected. Missing proof produces an explanation instead of a delta.

Legacy records keep their counts; an ordinary current refresh can collect new evidence, but cannot retrofit a historical observation.

When full visibility is unverified, additions and removals are labelled Observed scope. Visibility changes can affect these sets. Partial remains Partial, and completion-percentage change requires verified full scopes.

Retained issues newly counted, or no longer counted, as done are shown separately. Saved keys are paged in groups of 50 with access checked again. Changes reversed between captures and their reasons or authors cannot be inferred.

Sprint trends

The dashboard section draws Burn-up by sprint · percent done, one line per epic for the followed epics. Epic progress details has two more trend views.

Sprint trend shows one epic across up to 12 closed sprints ending at the selected sprint. Selected epics trend shows the chosen epics on a shared axis, with separate period tables.

Choose issues or story points, then Count or Percent. Count means known completed work present at each observation, not work completed during that sprint. Removing completed issues can lower it. Partial scopes have no percentage; unconfigured story points have an explicit gap.

Missing values, denied observations, and changed counting settings break the line. The table names the value or reason for each gap. Open a sprint in the table to inspect its retained observation.

Check saved trend and Check selected epic trends reread saved data and permissions; they do not collect Jira history.

Epics whose root is in Done with a resolution leave the trends, including older sprint views. Their saved observations remain available through Selected sprint and current values through Now. Reopening a root makes it eligible again on refresh.

Done without resolution remains in the trend with a warning; unknown or inaccessible root status hides it. Root completion is not inferred from the percentage of completed children.

A diamond marks a verified change in included member identities between adjacent observations. Status or estimate changes alone do not create it. Missing, partial, or incompatible observations do not imply unchanged scope. The table provides the same marker in text and opens the comparison.

No net change across two sprint intervals requires 3 consecutive verified observations with complete scopes, known outcomes and configured estimates, matching settings, and unchanged included identities and progress facts. Equal totals alone are insufficient.

Partial or missing observations prevent assessment; empty or completed work is not flagged. Changes reversed between captures are not visible.

Closed by year

On the dashboard, Closed this year · one point per epic on its closing date covers the followed epics closed in the calendar year (UTC) of the chosen sprint, up to that sprint’s close. The line above it reads, for example, “3 followed epics closed this year, up to …”.

In Epic progress details, Closed by year places the selected epics on a January to December axis; choose a year. Open roots and Done without resolution are excluded; Done-without-resolution roots are named below the chart.

Three or more closures in one UTC week form a +N group that opens a list. Individual points open epic details. Labels use up to 3 lanes above and below the axis; shortened names have their full text on hover. A table keeps the source, dates, and counts readable.

The date is Jira’s resolution date. If that field is explicitly empty, normal background refresh can establish the last entry into a status that is now in the Done category. This fallback is labelled Done transition · current status categories.

Missing or inconsistent history, unknown categories, and missing fields leave the date unavailable. A saved fallback is used only while the root’s status and update timestamp still match Jira. Page and gadget never load changelog. Background history reads are bounded; incomplete results do not invent dates.

Jira’s resolution date can appear before tracking is enabled. The fallback needs tracking and a saved collection. Until current progress is collected, the view says Counts unavailable. Collected counts retain their quality and timestamp: they describe the latest saved progress, not children reconstructed at the closure date.

Calendar dates and week boundaries use UTC. A sprint name means a unique visible board interval contains the date, not proven membership. Missing or overlapping intervals show Sprint unavailable.

Jira dashboard gadget

Edit your dashboard and add the QA Metrics — Epic progress gadget. Choose a team, enter 1 to 5 epic keys separated by commas, and set a title. Now needs no sprint.

Sprint trend requires a closed sprint and lets you save issues/story points and count/percent defaults. Closed by year lets you save a year without choosing a sprint. Tracking is managed on the QA Metrics page.

View buttons and the sprint/year selectors change the current session. Use gadget configuration to save defaults. Each epic keeps its own compact card; overlapping scopes are never added together. In the trend, Saved sprint selects one retained observation per epic.

Open saved epic observation opens the QA Metrics page with Epic progress details at the same epic, sprint and units. Now and year links also keep the selected epics and view, without requiring a sprint. The page checks your access again.

Refresh gadget rereads saved data and permissions. Gadget configuration stores selected identities and display preferences, not metric numbers or epic names.

Freshness and access

Updates to collected members request background refresh. Creation and hierarchy changes also check the current parent to discover new work for configured roots. Deleting a known member requests refresh. An hourly sweep requests recollection when the last capture is at least an hour old, dispatching up to 50 roots per sweep. Larger backlogs need further runs.

This repairs current values after missed events; it does not reconstruct missing history. Use the collection time to assess freshness. Durable requests survive uncertain queue delivery for later recovery.

Access is checked for the team, origin board, root, every required member, and historical sprint when applicable, including saved members subsequently removed from the epic. Denied aggregates are hidden, not reduced to a misleading smaller total. Other accessible selected epics can still load. Current results and history always retain their distinct collection times and settings.