Sprint Scope Guard — How to use

Sprint Scope Guard helps Jira administrators check whether one selected user has Manage Sprints permission across the proven project scope of a company-managed Scrum board. It diagnoses coverage and can monitor a healthy baseline. Changes to Jira remain manual.

Requirements

Install through the app's Atlassian distribution or Marketplace installation flow when available. Open Jira administration, go to Apps, and select Sprint Scope Guard. Jira administrator permission is checked on each app action.

Run a diagnosis

  1. Select a Scrum board.
  2. Select the Jira user whose Manage Sprints coverage you want to check.
  3. Choose Run diagnosis.
  4. Read the result and the identified projects. A result describes the fresh evidence available for that run; it is not a guarantee that Jira permissions will remain unchanged.

The app reports:

The app does not grant permissions, change filters, edit boards, start or complete sprints, or repair Jira configuration. Make any necessary Jira changes through your normal administration process, then run a fresh diagnosis.

Supported board filters

The supported filter forms are:

project = KEY ORDER BY Rank ASC
project IN (KEY, OTHERKEY) ORDER BY Rank ASC

Use unquoted project keys. Matching is case-insensitive. Additional predicates, functions, quoted keys, dynamic project selection, and other ordering expressions are outside this release's supported subset. A default Jira-created filter may therefore be unsupported even when it looks simple.

The app independently verifies that the filter projects match complete board-project evidence and are company-managed Software projects. A board label or partial project list alone is insufficient. Unsupported filters or project types return INDETERMINATE. If you decide to change an existing board filter, first review how that shared filter affects its other users and boards.

Enable and manage a Guard

After a SUFFICIENT result, choose Enable Guard with a fresh healthy baseline. The app reads Jira again before establishing the baseline. Each Guard belongs to one board and selected-user pair; multiple pairs can be monitored separately.

Scheduled evaluation is configured at five-minute intervals. Platform scheduling, API availability, configuration size, or failures can delay a completed evaluation. Check last evaluation time before relying on a monitor's state. Choose Rescan Guard for a fresh interactive evaluation.

Guard states distinguish permission regression, combined scope and permission regression, a diagnosis becoming indeterminate, a healthy scope change, and restored health. The previous valid healthy baseline is preserved through missing permissions or indeterminate evidence. A healthy scope change or restoration updates the baseline version; unchanged healthy evaluations do not create new versions.

Choose Remove Guard to delete that monitor's stored record. Review the privacy page for the retained data and account-level erasure lifecycle. A privacy update or erasure instruction may remove a user's Guards. Re-enable only after selecting the current user and obtaining a fresh SUFFICIENT diagnosis.

Limits

This release supports company-managed Scrum boards only. It does not evaluate team-managed boards, Kanban boards, arbitrary JQL, issue visibility, or every prerequisite for a successful Jira sprint action. Guard provides status in the administration page; it does not send alerts or notifications. Large-installation capacity is not established. Evidence or runtime limits fail closed as INDETERMINATE or unavailable rather than being reported as healthy.

Contact [email protected] for usage questions or reproducible defects. See Support, Privacy, and Security.