Sprint Scope Changes for Jira — User Manual
1. What this gadget shows
Sprint Scope shows what was added to and removed from a sprint while it was running: issue by issue, who made the change, when, and with how many story points.
It reads Jira's own change history. It writes nothing to Jira, and it sends no data outside Atlassian.
There are four views:
- Scope changes — every add and removal, as a list.
- Where removed issues went — out of every sprint, or into another one.
- Sprint trend — the same summary numbers for your recent sprints.
- CSV — the data as selectable text, ready to copy into a spreadsheet.
It works with boards that run sprints on Jira Cloud: Scrum boards and team-managed boards. Kanban boards have no sprints, so there is nothing to report. A team-managed Kanban board can still show up in the board list; if you pick one, the gadget tells you it has no sprints. Data Center is not supported.
2. Setting it up
- Open a dashboard and choose Add gadget.
- Add Sprint Scope Changes for Jira.
- In the gadget, pick a board and a sprint.
That is all. There is no configuration screen and no admin setup. The gadget remembers your board and sprint choice — each gadget keeps its own, so two gadgets on the same dashboard can show two different sprints.
3. Reading the numbers
3.1 Baseline ("In at start")
The baseline is what was in the sprint when it started. Jira does not store this — we reconstruct it from the change history, by working backwards from today.
3.2 Added, Removed, Net
- Added — issues that entered the sprint after it started.
- Removed — issues that left the sprint before it was completed.
- Net — added minus removed, in issues and in points.
Moves before the sprint started are planning, not scope changes. Moves after the sprint was completed are housekeeping, not scope changes. Section 4 explains both.
3.3 The estimate column
The column shows the estimate the issue had at the moment it moved, not its current estimate. This is deliberate: that is the number the sprint actually took on or gave up. See section 5.3.
If your board estimates by issue count, there are no story points to show, and the point columns are hidden — they do not become zeros.
3.4 Where removed issues went
Removed issues are grouped by where they ended up:
- Another sprint — the issue was moved from this sprint into a different one.
- No sprint — the issue left the sprint and was not put into another one. It went back to the backlog.
3.5 Copying the data
Open the CSV tab, choose Scope changes or Sprint trend, then click in the box, select all (Ctrl+A / Cmd+A) and copy (Ctrl+C / Cmd+C). Paste it into a spreadsheet.
There is no download button. Jira does not let a dashboard gadget hand you a file.
Text that starts with =, +, - or @ gets an apostrophe in front of it, so your spreadsheet reads it as text and not as a formula. Numbers are never changed.
4. What we can and cannot see
What counts as a scope change
A change that happened while the sprint was running: an issue entered or left between the sprint's start and its completion.
These are not scope changes, and that is deliberate:
- Moves before the start are planning. If you put an issue in before the sprint started, it did not "come in during the sprint" — it is part of the sprint.
- Moves after completion are housekeeping. If you cleared out the leftovers after closing the sprint, that did not affect the sprint. (The "In at start" number is still correct in that case: we count backwards.)
A move between sprints is two events
If an issue goes from Sprint 12 to Sprint 13, we count a removal from Sprint 12 and an addition to Sprint 13. Jira's native Sprint Report does not count it this way — if the numbers differ, this is usually why.
What we leave out on purpose
- Sub-tasks. A sub-task's Sprint field only mirrors its parent's; it has no moves of its own. Counting it would count the work twice. The report tells you how many sub-tasks it left out.
- Other boards. A report is always about one board and one sprint. The same issue can appear in the reports of two boards — that is correct.
Epics, on the other hand, are counted. Jira's board issue list does not return them, so we fetch them separately — without that, an epic moved in or out of the sprint would be invisible.
What we cannot show
These are not gaps we will fix later — Jira's data does not hold the answer. Better that you know about them:
- Deleted issues. Deleting an issue deletes its change history too. If an issue was removed from the sprint and then deleted, we have no trace of it.
- Issues you cannot see. The app asks Jira with your permissions. If an issue is hidden from you, its moves are missing from your report — and we cannot flag this, because a hidden issue looks exactly the same to us as an issue that never changed.
- Moved issues. If an issue was moved to another project, it can fall out of the board's filter, and its older moves fall out with it.
- A changed board filter. The report works with today's filter. If the filter was changed since an old sprint ran, that sprint's picture can be incomplete.
- Restarted sprints. Jira does not keep the earlier start date, so the report always uses the current one.
When the report could not check everything
On a large board, not everything fits in the available time. When that happens, the report says so, and gives you the number — for example "Scanned 2,500 of 4,000 issues". If you see this:
- the four summary numbers get a ~ mark, because they may not be the full picture;
- "no changes" does not mean nothing happened — it means we found nothing in what we checked.
The same applies when Jira temporarily limits our requests: the report shows the partial result and tells you where it stopped.
About story points
The estimate column shows what the issue's estimate was when it moved — not today's. If it was re-estimated since, the old value stays in the row, because that is the number the sprint actually ran with.
If your board has no story point field, the point columns disappear — they do not become zeros. And if two point fields are in use and we cannot tell which one is yours, we show no points rather than the wrong ones.
5. Frequently confusing things
5.1 "The numbers do not match the Sprint Report"
Jira's Sprint Report lists issues added after the sprint started. We list both additions and removals, and we count a move from one sprint to another as a removal from the first and an addition to the second. If the numbers differ, this is usually why.
5.2 "An issue is missing that we definitely removed"
We read Jira's change history for issues that are currently on this board. If an issue was deleted, or moved so that the board's filter no longer covers it, its history is out of our reach. Jira does not offer a way to find it.
5.3 "The story points are wrong"
We show the estimate the issue had at the moment it moved, not its current estimate. An issue pulled in at 3 points and re-estimated to 13 later counts as 3 — that is what the sprint actually took on. The estimate field comes from your board's configuration.
6. Permissions the app asks for
| Permission | Why |
|---|---|
read:board-scope:jira-software | To list your boards and the issues on them. |
read:sprint:jira-software | To list sprints and their start and end dates. |
read:issue-details:jira | To read issue keys, summaries and estimates. |
read:jql:jira | To look up the issues in a sprint. |
read:project:jira | To know which projects a board covers. |
read:epic:jira-software | To read epics — a Scrum board's issue list leaves them out. |
read:jira-work | To read the change history in bulk — this is how the app knows what moved. |
storage:app | To remember which board and sprint this gadget shows. Nothing leaves Atlassian. |
The app has no write permission. It cannot change anything in Jira.
7. Data and privacy
The app reads Jira's change history through Atlassian's own API, with your permissions. It writes nothing back, and it makes no network calls outside Atlassian. The only thing it stores is the board and sprint choice for each gadget, on Atlassian's app storage; that is deleted when you uninstall the app.
[ Full privacy statement → ]
8. Getting help
Email: support@axerilabs.com
We reply within two working days. Written support in English.
If Atlassian classifies an issue as critical, we reply within 24 hours, weekends included. A reply means we have read your report and told you what happens next. It does not mean the fix is ready: we do not promise a fix time.
We do not offer phone, video or live chat support.
If the report shows something you did not expect, please read section 4 and section 5 first — most differences from the native Sprint Report are explained there. If yours is not, write to us: tell us the board, the sprint, and the issue key you have a question about.