Every scrum master has asked it at some point in a review: what got added after we committed? Jira knows the answer, because every change to the Sprint field is in the issue history, but for eight years it has only shown it one way: the asterisk next to an issue in the Sprint Report. The request to make it a JQL query, JRACLOUD-75868, has more than 1,400 votes and is still "Gathering Interest". Here are the four ways teams answer the question today, what each one can and cannot do, and when each is enough. Disclosure up front: I am building the fourth one.
Open the board, Reports, Sprint Report, pick the sprint. Issues added after the sprint started carry an asterisk; the footnote says so. "Issues Removed From Sprint" is its own section at the bottom, and the completed and not-completed lists are above it.
It is accurate, it is retroactive (every closed sprint is there), and it costs nothing. What it cannot do: it is a page, not a query. You cannot filter on it, sort by it, put it in a dashboard gadget, trigger automation from it or export it without copy-and-paste. For one sprint in a retrospective it is fine. For "how much scope creep did we have per sprint this quarter" it means opening twelve reports and counting asterisks.
Also note two details that trip people up: subtasks are excluded, and an issue that was in the sprint at start, removed and put back is not asterisked, because Jira compares the start state with the end state rather than counting events.
The workaround people post in the ticket thread: stamp each issue when it enters an active sprint and query the stamp.
sprint = {{sprint.id}}) and set "Sprint scope" to Committed.sprint in openSprints() and "Sprint scope" is not Committed; action: set "Sprint scope" to Added after start and "Added to active sprint" to {{now}}.sprint in openSprints() AND "Sprint scope" = "Added after start", or by date with the custom field.It works, and it is the right answer if you only care about the current sprint from now on. The limits: it is not retroactive (nothing before the rule existed is stamped), a single field per issue cannot hold the history of an issue that rolls over three sprints (rule A overwrites it at the next sprint start, so "added after start" in sprint 41 becomes "committed" in sprint 42), removals need a third rule and another field, and every rule run counts against the site's monthly automation allowance (100 runs a month on Free, 1,700 site-wide on Standard, 1,000 per user on Premium at the time of writing). Expect an afternoon to set up and a support conversation every time someone asks why the numbers differ from the Sprint Report.
JQL Search Extensions (Appfire) adds functions that Jira does not have, and one of them is this: issue in addedToSprintAfterStart("ACME board", "ACME Sprint 5"), with the board first and the sprint optional (the active sprint by default). It is retroactive, it works wherever JQL works, and it is a mature product with thousands of installs. If your site already pays for it, this is the answer and you can stop reading.
If it does not: the function covers the "added" half only (there is no "removed", "committed" or "carried over"), the result is a query rather than a column you can sort or show in a gadget, and the app is a large toolkit priced accordingly (list price is roughly $175 a month for a 100-user site at the time of writing; check the listing). Buying it for one function is like buying a workshop for one screwdriver.
Sprint Ledger is a Forge app that does one thing: it reconstructs the membership history of every sprint on the site from the changelog, keeps it current from Jira's events, and exposes it three ways.
addedAfterSprintStart(sprint?), removedFromSprint(sprint?), committedTo(sprint?), completedIn(sprint?), carriedOverFrom(sprint?) and carriedOver(n). Without an argument they mean the active sprints. They work in filters, boards, dashboards, automation and subscriptions."Sprint start (Ledger)" >= 2026-07-01.It is retroactive for every sprint the site has run, it follows the Sprint Report's definitions (so the numbers match, and the differences are documented), and it runs entirely inside Atlassian's infrastructure, so no issue data leaves Jira. It is on the Atlassian Marketplace, priced so that a 100-user site pays about $50 a month and sites with up to 10 users pay nothing.
| Sprint Report | Automation rule | JQL Search Extensions | Sprint Ledger | |
|---|---|---|---|---|
| Added after start | asterisk on a page | current sprint onward | JQL, per board and sprint | JQL, column, gadget, CSV |
| Removed from sprint | section on a page | third rule and field | no | yes |
| Committed, completed, carried over | lists on a page | no | no | yes |
| Retroactive for closed sprints | yes | no | yes | yes |
| Sortable column, gadget, export | no | column only | no | yes |
| Automation and subscriptions | no | yes | yes | yes |
| Cost for 100 users | free | free (rule runs) | about $175 a month | about $50 a month |
| Setup | none | an afternoon | install | install and wait for the backfill |
If you look at one sprint at a time, the Sprint Report is enough. If you only need the active sprint from today on and are comfortable with automation, the rule is enough. If you already own JQL Search Extensions, use it. If you want the whole history as queries and columns, or you report across teams, that is the gap Sprint Ledger is meant to fill, and I would like to hear where it is wrong: support@dyordanov.com.
Questions and corrections about the first three methods are welcome in the comments; I will keep the table current.