An active sprint can change for good reasons: an incident, a customer escalation, or new information. The useful question is what the team can still credibly complete after that change.
Start with Jira’s Sprint Report
On a company-managed Jira Cloud Scrum board, open Reports → Sprint Report and select the sprint. Atlassian says the report marks work items added after the sprint started with an asterisk. Check the board filter before treating the list as complete: the report reflects that board, and its column mapping affects the To Do and Done categories. Atlassian’s Sprint Report guide covers company-managed spaces. If you use a team-managed project, confirm the equivalent view in your own setup.
Run a short scope conversation
- List the additions. Capture the issue keys and the report you used.
- Ask why they entered. Separate a real emergency from work that can wait.
- Name the trade-off. If this work stays in the sprint, what moves out, pauses, shrinks, or loses priority?
- Record the decision. Add the reason, owner, and next check-in to a Jira comment or team note.
Keep the discussion about capacity and priority, not blame. The report shows a change; it does not decide what the team should do about it.
When a current-sprint workflow helps
Sprint Scope Guard opens inside a Jira project. For an active sprint, it separates remaining pre-start work from issues added after start. Authorized users can approve an addition, return it to the backlog, or pair it with a scope swap; they can export the current result. It does not reconstruct the original commitment or provide closed-sprint history. Use Jira’s native reports when their reporting view is enough, and use the app when the team needs to agree and record an action now.
Disclosure: I build Sprint Scope Guard. Jira’s native Sprint Report may be enough for your team.