Requirement coverage

Requirement coverage measures completed requirements with matching automation evidence. It does not measure source-code coverage or test execution results.

On the dashboard

For a closed sprint, the tile and the section show the value saved at that sprint’s close. The tile notes “Saved just after the sprint closed.” and its change “Compares the coverage saved at each sprint’s close.” For an active sprint, they show the current value.

When no close value can be used, the tile falls back to comparing current values (“Compares the latest coverage of each sprint’s requirements.”), and the section says “No value was saved at this sprint’s close; the numbers show coverage now.”

The Requirement coverage section shows “Requirements with tests behind them” and has two switches: By sprint / By epic and Count / Percent. By sprint shows:

• … · requirements by state: Covered, Coverage in progress, Deferred, Uncovered, Not required and Unknown.
• Trend by sprint · covered at close and covered now, with the lines Covered at sprint close and Covered now. Hovering a sprint shows “Covered at close”, “Covered now” and the gap.

By epic shows current coverage by epic, as described below. Selecting the section title opens Requirement coverage details; the sliders button opens Requirement coverage settings.

Settings

Choose the team’s requirement issue types and one automation preset in Requirement coverage settings: a linked issue, a sub-task, or an exact label on the requirement. Optional conditions narrow the requirements; cancellation resolutions exclude cancelled work.

Excluded requirements leaves out work that does not need automated tests, for example a no-automation label or a project without tests: a requirement matching any exclusion group is not counted, like a cancelled one, and a requirement whose labels or project cannot be read stays Unknown. Saving rules never creates Jira fields or changes Jira issues.

Settings are off until explicitly enabled. Closed sprints keep the rules they were counted with.

Current coverage

In Requirement coverage details, expand Requirement coverage · current, choose an active Coverage sprint or the closed sprint chosen in the dashboard header, and Load current coverage to read the last collection. Collect current coverage asks for current Jira facts in the background. The collection time is shown.

A pending request can outlive the short progress check; load again later. Reading a saved value does not start collection. Changing settings invalidates old current values and requests recollection of existing sprint positions.

The current cohort is the configured requirement types associated today with the selected sprint in Jira. Requirements must satisfy the configured conditions and be in Done status category with a resolution, excluding configured cancellations.

Jira search must finish, and current-user access to every requirement and automation dependency is checked before display. A completed visible search does not establish hidden issues or an atomic historical snapshot.

• Covered: all matching automation facts establish Done with resolution, or the configured label is present. One automation issue may supply evidence to several requirements.
• In progress (Coverage in progress in the dashboard section): matching unfinished automation includes work in the selected sprint.
• Deferred: matching unfinished automation exists outside the selected sprint.
• Uncovered: matching automation is proven absent, or the configured label is absent.
• Not required: a saved exemption has a verified reason and author.
• Unknown: the required facts or exemption cannot be established. This is not Uncovered.

Coverage = covered requirements divided by developed requirements minus Not required. Example: five developed requirements, one each Covered, In progress, Deferred, Uncovered and Not required, gives 1 / (5 − 1) = 25%. The state distribution includes Not required, so each state in that example is 20%. Count and Percent change the distribution units; the headline retains the coverage formula.

Complete means the current observation has a complete enumerated cohort and no unknown coverage facts. Partial keeps Unknown visible and withholds the percentage. A denied, incomplete or invalid cohort shows no aggregate. No developed requirements and all-exempt requirements have no percentage; a known nonempty cohort with no covered requirements is 0%.

For a closed sprint, the Current view in the details panel is still current, using current sprint association and Jira facts. Later automation and membership changes can change it. It is not coverage at the exact close; the dashboard tile and section show the close value instead.

Daily history

In the details panel, choose Daily history, Load saved coverage days, then a UTC date. Each date preserves its first successfully saved observation, original collection time, quality, rule version and exemption revision. Later collections update Current without changing that day.

For example, a saved day can remain 1/2 = 50% after late automation makes Current 2/2 = 100%.

Manual collection saves a daily observation. Existing collected sprint positions also refresh through the hourly background recovery, once successfully per UTC day while coverage is on. This includes supported closed sprints. Enabled teams automatically enroll active board sprints through sprint-start events and hourly recovery; Collect can start sooner.

Failed or paused days remain gaps, never zeroes or invented backfill. Old collections without sprint-window evidence do not become historical snapshots retrospectively.

A daily value is an observation at its displayed time, not the exact end of the day or sprint close. Reading it checks current access to all original dependencies and the sprint window. Changed rules stay recorded under their original version; disabled coverage or unverified access hides the value. Earlier coverage days loads older dates in bounded pages.

Close observation

Enable coverage before a sprint closes. The sprint-close event creates a durable capture request under the rules effective at that first close. This saved value is what the dashboard tile and section show for a closed sprint. In the details panel, Close observation → Load close coverage reads the first saved result.

The background queue retries failed collection; reload checks its status. Opening this view never reconstructs old sprints or starts a collection.

A saved close observation stays unchanged when automation is completed later. For example, close coverage can stay 1/2 = 50% while Current becomes 2/2 = 100%. The capture shows the sprint close time, when collection began, when it finished, and saved rule/exemption versions.

It uses Jira facts observed after close, so historical accuracy is Partial: the exact state at the closing instant is unverified. Counts and percentages describe the saved observation; unknown requirement/automation facts still withhold percentages.

No captured observation is a gap, not zero. Reopening or changing the sprint window shows window-changed with an explanation; the first close is preserved and no replacement point is created. Current access to every original dependency is required to read the saved count.

Current coverage by epic

Select By epic in the dashboard section or in the details panel, with the sprint chosen in the header as the reference sprint, and add an accessible epic by its Jira key. Select up to ten epics in one view. Each row covers all direct requirements of that epic through the standard parent field, across all sprints.

The reference sprint only distinguishes unfinished automation In progress in that sprint from Deferred outside it. The same requirement types, conditions, automation preset, Done/resolution rules and Not required markings apply.

Adding an epic or Load epic coverage reads its saved collection. Collect epic coverage requests current Jira facts in the background. Each row shows its collection time, five states, covered numerator/denominator and percentage; Count/Percent switches the state table. Sort by name or lowest coverage first.

Completed epics are folded at the end. Missing facts withhold the percentage; denied access hides the row’s name and value. Rows are not added together.

This is current epic coverage. It does not reconstruct the epic at a historical sprint close and does not change sprint Current, Daily history or Close observation. Reselecting an epic after a page reload reads its saved collection.

Changes to coverage settings or Not required markings invalidate old values and are recovered in the background; collect again to refresh changed Jira facts. A changed reference-sprint window also requires collection. Limits or an incomplete search produce an unavailable value rather than a truncated percentage.

Current headline and change from the previous sprint

On the dashboard, a closed sprint’s change compares close with close under the same board, formula, rules and Not required markings. The tile shows it as whole points, for example ”▲ 50 pts”. Without a usable close value it uses the current comparison below.

In the details panel, the Current view includes the Requirements covered now headline. Count shows confirmed covered requirements; Percent uses covered divided by developed requirements minus Not required. The chart’s Count/Percent switch also changes the headline.

Empty and all-exempt denominators show an unavailable percentage, never an invented zero. Unknown facts keep a qualified known count and withhold percentage and comparison.

Compare previous sprint reads saved current facts for the immediately preceding closed sprint on the team’s board. For an active sprint, the previous sprint must have closed by the active sprint’s start. Closed sprints are ordered by closing time, then ID to break ties.

The previous period is resolved from current authorized Jira metadata; missing data does not cause an older period to be substituted. Count changes use covered requirements; percentage changes use percentage points (50% to 100% is +50 percentage points).

Both periods use Current, so later automation can change either value. They are not exact historical coverage at close. The headline shows both collection times.

Changed board/rules/Not required revision, unknown facts, collection in progress, missing metadata or denied access leave a comparison gap with a reason. Reading/comparing does not queue a collection. Changes to selection or selected data clear old comparisons.

Jira dashboard gadget

Add QA Metrics — Requirement coverage to a Jira dashboard. In Edit, choose an accessible team, an active or closed sprint, the initial Count/Percent unit and a title. Save verifies the team and sprint again. Configuration does not grant access to the underlying requirements; every displayed value still requires the current viewer’s access to all retained dependencies.

The gadget automatically reads the selected sprint’s saved Current value. It shows the same five states, headline, quality and collection time as the details panel. Compare previous sprint shows the saved Current comparison with its usual gaps and safeguards. The sprint selector can explore another available sprint; Return to configured sprint restores the saved choice.

A configured active sprint remains available after it closes, still as Current coverage.

The gadget only reads saved data; Load and Compare also only read, and there is no Collect button. Enable coverage and collect missing facts in Requirement coverage details first. The gadget shows Current and Sprint trend; daily history, close observations and By epic remain on the details panel. Current values for closed sprints can change after later automation.

Coverage across sprints

Choose Sprint trend in the details panel or the coverage gadget, then Load coverage trend. The chart shows up to 12 successive sprints ending at the selected sprint. An active selected sprint has Current only; its close observation is unavailable until a supported collection following closure. The chart reads saved data and does not start collection.

Green circles show Current; blue diamonds and a dashed line show Close observation. Switch between covered requirement counts and percentages. Close observations are always marked Partial because collection happened after closing; they do not prove the exact state at close.

Each point’s quality, collection time, rules version and Not required revision appear in the table. Open a sprint from its row to inspect Current on the same page or gadget.

Missing collections remain gaps. Empty or all-exempt denominators have no percentage; unknown facts also hide percentages while known covered counts remain qualified as Partial. Lines break when observations are missing or their rules/marking revisions differ. Later automation can change Current.

A visible difference between the two series alone does not establish an automation debt amount when the rules, scope or observations differ.

The trend clears earlier results while loading and when its checks detect changes to the team, sprint windows, enabled state, counting rules, markings or access. Every numerical point still needs fresh access to its full required issue set. Values have individual collection times; the trend is not a simultaneous collection or a claim that separate generations changed atomically.

Automation debt and requirements

Current in the details panel and the gadget shows Automation debt: In progress + Deferred + Uncovered requirements awaiting completed automation. Covered, verified Not required and unfinished/excluded requirements do not enter the count. A Partial collection labels this as known requirements; Unknown is reported separately and is never treated as zero or debt.

Choose Requirements to list, then Load requirements. The default lists all three debt states; the other choices show each state separately or Unknown with its missing-evidence reasons. Pages contain up to five Jira keys and their saved coverage state. Previous/Next requirements navigate the list.

Open a key to inspect its current issue in Jira; a moved issue can have a new key without changing its saved coverage facts. No issue text, authors or changelog are read.

The list belongs to the same Current collection as the displayed count and timestamp. Loading another choice clears the previous rows. Every list read checks access to the whole saved dependency set and then rechecks the team, rules, markings and generation after resolving keys.

A changed collection or failed access check clears both counts and rows; reload Current. Reading the list never recollects coverage. This count does not measure debt age or automation lag.

Automatic first collection

After requirement coverage is enabled, active sprints on the team’s board join background collection automatically. An ordinary sprint-start event schedules discovery; the hourly sweep recovers missing events and teams enabled after their sprint already started.

Discovery visits up to 50 enabled teams per sweep with a persistent cursor, so larger installations can require several passes. Future and unrelated-board sprints are not enrolled from a queue hint.

Load current coverage reads the saved result. Collect current coverage in the details panel can request it sooner. The dashboard gadget reads saved coverage without collecting. First successful collection also saves the UTC day’s observation. Repeat discovery preserves clean generations, collection times and existing daily/close snapshots.

An uncertain queue response leaves a durable pending request for recovery. Discovery uses complete active-board metadata, bounded to 100 active sprints; it does not silently enroll a truncated page or read issue histories.

Create a linked automation task

For a team using the linked-task preset, load Current coverage and its uncovered-requirement list. Choose Create automation task on a requirement, select a rule option, task type and link type, then open Jira’s create form.

The form starts with the requirement’s project, Automate <issue key> as the summary, and the selected rule’s labels and components. Review the fields and any additional fields Jira requires before choosing Create.

Cancelling the Jira form creates nothing. After creation, the app checks your current access, the requirement and the task against the team’s current rules, then adds the selected link. If the link cannot be verified, Retry linking created task retries that link only; it does not create another task.

If Jira did not confirm the form’s result, check Jira before opening another create form. Changing teams or closing the action stops subsequent callbacks.

Creating a task does not mean the automation is finished. In the details panel, use Collect current coverage, then Load current coverage to see its actual state; the gadget reads the same saved collection. An unfinished automation task can move a requirement from Uncovered to Deferred or In progress while the covered count stays unchanged.

Saved days and Close values remain unchanged. The Subtask preset has its separate create action described below.

Automation lag

In Current in the details panel or the gadget, choose Load automation lag. The list shows up to five covered requirements per page, their successful Done dates and the number of board sprints between the requirement and its last required automation task.

For example, a requirement completed in sprint 4 with two automation tasks completed in sprints 4 and 6 has a lag of 2 sprints. Both completed in the same sprint means 0. Automation already complete before the requirement also means 0; no negative lag is shown.

Done requires the Done status category and a known, non-cancelled resolution. A move between two Done statuses does not reset completion. A reopen followed by completion starts a new episode; a resolution added later starts completion then. These are current workflow categories and automation rules, not a reconstruction of old configuration.

All tasks the current rules require must be successfully Done. The label preset has no separate task completion event and shows Not applicable.

Each completion must belong to one unambiguous board sprint. Actual starts and closes are used; planned end dates are not completion boundaries. At a shared boundary, the later sprint owns the event. Gaps between sprints add no sprint.

Overlapping periods, dates in gaps, missing or inconsistent history and created-in-Done issues without a proven transition leave lag unavailable with an explanation. An unavailable lag is never shown as zero.

Lag is collected in the background with Current coverage, never while a page or gadget renders. A collection reads at most 40 distinct requirement/automation histories, 160 additional Jira requests and 10 pages per history or calendar, with a 120-second elapsed budget. The existing bounded cohort search runs again to verify dependencies.

Reaching a limit leaves lag unavailable while retaining ordinary coverage; it does not report a smaller measured cohort. The verification search shares the elapsed-time deadline. Reads use saved results after checking current access to every required issue and to the board periods used in the lag.

Older collections show Lag has not been collected. Use Collect current coverage in the details panel, then load the new result. Daily and close snapshots remain unchanged. Lag describes the saved Current observation; it is not continuous debt age or a test-run result.

Create an automation subtask

With the Subtask preset, an Uncovered row offers Create automation subtask in the details panel and the gadget. Select an automation rule option and a subtask type, review the parent and fields, then click Create automation subtask. Closing the action before that click creates nothing.

The new subtask uses Automate <requirement key> as its summary, the selected rule’s labels/components and the requirement as its parent.

A subtask inherits its parent’s sprint. An unfinished matching subtask under a requirement in the selected sprint therefore produces In progress, while the covered count stays unchanged. For example, creating one subtask for two previously Uncovered requirements leaves coverage 0/2 = 0%, with In progress 1 / Uncovered 1.

A later Current collection reads that state; existing Daily and Close observations keep their original values. The subtask preset also uses the parent’s verified membership in the by-epic view, where requirements may be outside the selected reference sprint.

Creation requires current access to the team, requirement and its children, Jira Create Issues permission and compatible create fields. The app supplies the parent, project, type, summary and rule fields only. If Jira requires another field without a default, create the subtask from the parent in Jira. Fields on the requirement are not changed.

If Jira refuses creation, Review subtask creation reloads the choices before a new explicit attempt. If the outcome is uncertain, Check created subtask only checks; it never creates another. Open the parent in Jira before manually creating anything else. Refreshing the page or changing the sprint cannot automatically repeat an uncertain creation.

A previously created task that becomes hidden or is deleted requires checking Jira; the app does not treat missing access as proof that another task is needed.

Deferred debt age

Choose Load debt age in Current in the details panel or the gadget. The list shows Deferred requirements in groups of five, oldest verified age first. Each numeric row shows its continuous Deferred start and observation time. Unavailable ages appear last with a reason; they are never treated as zero.

Age measures board sprint distance during the current continuous Deferred episode. A requirement that became Deferred in sprint 4 and remains Deferred in sprint 6 has age 2 sprints. Entering Deferred in the observation’s sprint gives 0. Issue creation and the first time the app saw the issue do not establish the age.

Adding another unfinished backlog task or changing between Deferred configurations does not restart it. A verified interval outside Deferred does: for example, all automation becoming covered, automation entering the selected sprint, or a Not required marking. Clearing a marking starts a new eligible interval.

This uses current rules and workflow categories, with successful Done requiring resolution. Missing histories, unreconciled links, changes to rule fields that cannot be reconstructed, or conflicting evidence leave age unavailable while ordinary verified coverage stays visible.

Deleting a linked Jira task can remove the current link without a new history entry, so the app does not invent a deletion time. Actual board sprint starts and closes determine distance; overlapping calendars or a start/observation in a gap cannot yield a numeric age.

Age is collected with Current in the background, with a limit of 40 distinct issues, 160 extra Jira reads, 10 pages per history/calendar and 120 seconds, sharing the worker’s 240-second collection deadline with automation lag. A verification cohort search shares that deadline.

The page and gadget read saved results after current issue and period access checks. Older collections show that age has not been collected; use Collect current coverage in the details panel. Daily and Close snapshots stay unchanged.

Subtasks inherit the selected requirement’s sprint and therefore unfinished matching subtasks are In progress in this Current view; the label preset also has no Deferred requirements.

Project conditions

In requirement or automation conditions, choose Project, then Load projects and select a project you can browse. Combine it with labels, components or issue types using the existing AND/OR groups. The rule stores the project’s ID, so renaming its key or name keeps the match. Selected IDs are checked again when saving.

If a project is no longer available, its saved selection stays visible and enabling waits for a valid selection; it is never silently replaced.

For example, a linked task in SHOP can match Project = SHOP AND Label = automation even when its requirement is in SCRUM. A linked task in SCRUM does not match that branch. Missing project facts stay unknown, and the app still verifies access to all required dependencies, including tasks excluded by the rule.

Current values are recollected after settings changes; saved Daily and Close observations retain their original configuration and values.

The existing create helpers create in the requirement’s project. They offer only branches that can be satisfied there; a subtask must stay with its parent. Create and link cross-project automation in Jira when its project condition cannot be satisfied by the helper. No task is created by changing a rule.

The project catalogue is loaded on demand, limited to 1,000 projects within the settings request deadline; an incomplete result cannot enable a rule.

Coverage on a Jira issue

Open View app actions → Requirement coverage on the Jira issue. Choose the team and an active or closed sprint, then Load issue coverage. The panel reads that issue from the same saved Current facts used by the QA Metrics page, with the collection time and Complete/Partial quality. Reload after automation changes have been collected.

It does not show a frozen closing value or collect Jira history when opened.

Covered, In progress, Deferred, Uncovered, Not required and Unknown retain the same rules as the page. A required automation issue closed with a configured cancellation resolution makes its requirement Unknown rather than covered or unfinished.

An issue outside the developed cohort or absent from the selected sprint’s cohort is shown separately; neither means Uncovered. Choose another team/sprint if needed. Changing the selection clears the previous result. To collect facts or change rules, use the QA Metrics page. Manage the not-required marking in the issue panel.

The app checks current access to the team board and every issue needed by the saved observation, including this issue. If that proof fails, the panel withholds the state. Jira itself shows the add-panel button only to users who can edit the issue; this platform restriction does not grant permission to change QA Metrics settings.

Platform reference (verified 2026-09-15): https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-issue-panel/

Not-required markings and reasons

In the issue panel, choose the team/sprint and Load not-required marking. The marking applies to this requirement for that team across sprints. A saved reason, marking time and View marking author link identify the decision. Enter a non-empty reason (up to 500 characters) and save, or clear the marking.

Both actions use the current user’s board and issue access; the server records the acting author. Clearing retains the audit record.

Saving clears the displayed Current state and requests recollection. Load Current again after the new collection is published; a confirmed marking does not mean the headline has already changed. If a write cannot be confirmed, load the marking before retrying.

On the Current page or gadget, Load not-required reasons groups the developed sprint’s verified exclusions by their exact saved reason. Text is normalized when saved; capitalization and different wording remain distinct. Each requirement counts once, authors are never grouped or counted.

The report shows 10 reason groups per page; paging uses the same loaded report and makes no new Jira request. Reload Current after a change.

The report is withheld if access, cohort, reason/author evidence or collection identity cannot be verified. A verified empty report says no not-required requirements; missing evidence is not an empty report. If every developed requirement is Not required, the coverage denominator is zero and the percentage stays unavailable.

Current reasons are not an audit of reasons at sprint close and do not rewrite historical snapshots.

Automation category counts

Configure Work categories in Sprint commitment settings to add category counts to the Current coverage headline in the details panel and the dashboard gadget. The existing editor uses labels, components and issue types. No additional Jira fields are created.

Only proven Covered requirements contribute. With linked automation or subtasks, a requirement counts once in each distinct category of its mandatory automation tasks. Three UI tasks for one requirement contribute UI 1. One UI task and one API task contribute UI 1 and API 1, while the main covered count is still 1.

A shared task contributes once for each covered requirement it supports. With the label preset, the covered requirement’s own fields determine its category.

A task matching several categories, no category or an unknown condition is Unclassified. Each requirement counts at most once in Unclassified, even if several tasks are unclassified; it may also occur in a named category. Consequently category counts can overlap and must not be summed to obtain the coverage total.

Configured categories and Unclassified remain visible at zero. Unknown coverage, unfinished, excluded and Not required requirements are not counted in this breakdown.

The headline names the current work-rule version and applies it to the same saved facts as the coverage value. Reload Current after editing categories; its collection timestamp stays unchanged until a collection runs. Frozen Daily and Close values are not rewritten. Without configured categories, the optional breakdown is hidden.

Older collections lacking category facts show an unavailable message until a normal Current collection.

Each category field is stored completely or is unknown if missing or above its 256-byte JSON limit. Optional category facts never reduce existing row/generation capacity: if they would exceed a storage bound, they are omitted and the breakdown is unavailable. The main coverage calculation retains its original facts. Unsupported rule fields remain unknown.

Category display reads saved rows; it does not fetch live issue fields or histories.