Initial sprint scope is the work included when the sprint starts. Final sprint scope is the work included at the chosen end snapshot. Completed work is a separate measure. To explain the difference, track additions, removals, and estimate changes using a consistent unit and issue set.
To report sprint rollover in Jira, use the closed Sprint Report as the historical source, then reconcile five distinct groups: committed, added, removed, completed, and carried over. Do not call every incomplete item rollover: an item is carried over only when it was incomplete at close and was assigned to the next sprint.
This guide uses an explicit accounting convention for a synthetic sprint. Jira reports can apply their own board, hierarchy, and estimation rules, so reconcile those rules before expecting a custom spreadsheet to match a chart.
Download the Jira sprint rollover reconciliation sheet to classify one issue per row and reproduce the worked example.
Write down the report boundary
For the company-managed Scrum Sprint Report, Atlassian documents three relevant constraints: the report uses the board's saved filter, it excludes subtask estimates from its estimate totals, and it marks work added after sprint start. Completion also depends on board column mapping. Atlassian Sprint Report documentation.
Record the board, sprint, start and end timestamps, timezone, estimation statistic, and included issue types. If the board filter changes, note that before comparing successive reports.
Choose story points, hours, or issue counts according to the question. Do not combine points and hours in one scope total.
How to report sprint rollover in Jira
Use this close-of-sprint sequence:
- Open Reports → Sprint Report for the board and select the closed sprint. Save the sprint ID, start and completion times, board filter, estimation statistic, and timezone.
- Record the issues present at sprint start as committed. Use the Sprint Report and its scope-change evidence to classify work added or removed after start.
- Record which final-scope issues Jira counted as completed. Jira uses the board's right-most column as Done, so verify the column mapping before accepting the result.
- Record final-scope issues that were incomplete at close. Atlassian lets the person closing the sprint move those issues to the backlog or another sprint.
- Mark an issue carried over only when it was incomplete at close and its chosen destination was the next sprint. Preserve the closed-sprint snapshot even if the issue finishes later.
- Publish issue counts or one consistent estimate unit for all five groups, then show gross and net scope change separately.
| Measure | Definition | Do not confuse it with |
|---|---|---|
| Committed | In the sprint at its start snapshot | Everything that eventually appeared in the sprint |
| Added | Entered the sprint after it started | Estimate growth on an issue already in scope |
| Removed | Left the sprint before close | Incomplete work still present at close |
| Completed | Final-scope work Jira counted Done during the sprint | Work completed later in the next sprint |
| Carried over | Incomplete at close and assigned to the next sprint | Removed work or work returned to the backlog |
Jira's burndown report includes a scope-change log plus tables for incomplete, completed, completed-outside-sprint, and removed work. Use those historical classifications rather than trying to recreate the close state from today's status alone.
Saved-filter and dashboard example
Use numeric sprint IDs so a renamed sprint does not change the filter. Replace DELIVERY, 123, and 124 with your project key, closed sprint ID, and next sprint ID.
project = DELIVERY AND Sprint = 123 ORDER BY Rank ASC
Save that filter as DELIVERY Sprint 123 reconciliation. Add a Filter Results gadget to the dashboard and show Key, Summary, Status, Sprint, Assignee, and Story points. The gadget is an issue list for review; it does not calculate historical additions, removals, or rollover totals.
Immediately after rollover, this second filter finds issues whose Sprint field contains both sprint IDs:
project = DELIVERY AND Sprint = 123 AND Sprint = 124 ORDER BY Rank ASC
Save it as DELIVERY 123 → 124 rollover candidates and use it in a second Filter Results gadget. Treat the rows as candidates, not proof: Jira permits an issue to belong to completed and incomplete sprints, while current JQL does not prove that the issue was incomplete at the earlier sprint's close. Confirm each candidate against the closed Sprint Report or the reconciliation sheet snapshot.
A six-issue sprint you can reconcile
Assume four parent-level issues are present at sprint start. Their estimates remain unchanged throughout this example. Two issues are added later, and one original issue is removed before completion.
| Issue | Points | Committed? | Change during sprint | Completed? | Carried to Sprint 43? |
|---|---|---|---|---|---|
| SCOPE-1 | 8 | Yes | None | Yes | No |
| SCOPE-2 | 5 | Yes | None | Yes | No |
| SCOPE-3 | 3 | Yes | Removed | No—outside final scope | No |
| SCOPE-4 | 4 | Yes | None | No | Yes |
| SCOPE-5 | 5 | No | Added | Yes | No |
| SCOPE-6 | 3 | No | Added | No | Yes |
The reconciliation is:
Initial scope = 8 + 5 + 3 + 4 = 20 points Added scope = 5 + 3 = 8 points Removed scope = 3 points Final scope = 20 + 8 − 3 = 25 points Completed final-scope work = 8 + 5 + 5 = 18 points Incomplete final-scope work = 4 + 3 = 7 points Carried over to Sprint 43 = 4 + 3 = 7 points
The Jira sprint rollover reconciliation sheet contains these six rows, including rollover destination and classification notes. The original synthetic sprint-scope dataset remains available for the narrower initial-versus-final calculation.
In a spreadsheet, the issue-level columns make these summary formulas copyable:
Committed points = SUMIF(E:E,"Yes",D:D) Added points = SUMIF(F:F,"Yes",D:D) Removed points = SUMIF(G:G,"Yes",D:D) Completed points = SUMIF(I:I,"Yes",D:D) Carried-over points = SUMIF(K:K,"Yes",D:D) Gross scope change = added points + removed points Net scope change = added points - removed points
The team completed 18 points, including five points added after the start. It completed 13 of the original 20 committed points. Those are both valid observations, answering different questions.
Reconcile an estimate change separately from added work
Now extend the same fictional sprint: SCOPE-4 stays in scope, but its estimate increases from four to six points. This is a two-point re-estimation of existing work. Keep it separate from the eight points added through SCOPE-5 and SCOPE-6.
The change ledger records each initial amount and subsequent adjustment once:
Initial 20 + added 8 − removed 3 + re-estimated 2 = final 27 points Completed final-scope work = 18 points Incomplete final-scope work = 9 points
The incomplete total changes because SCOPE-4 is still incomplete at close. Completion remains 18 points in this example. The local calculation checks all eight ledger entries and the 27-point total; the change types are our accounting labels, not a promised Jira export format.
This is a separate scenario from the unchanged-estimate example above. Preserve both the original values and the adjustment: overwriting the starting four points with six would make the original commitment appear larger than it was. When reconciling a real report, check its snapshot and re-estimation rules before applying this convention.
Show gross changes as well as the net change
In the original unchanged-estimate example, final scope increased by five points, or 25% of the starting 20. That net figure hides eight points of additions and three points of removals.
Gross scope change counts all membership movement: 8 added + 3 removed = 11 points, or 55% of the initial scope. Net scope change records only the balance: 8 added - 3 removed = +5 points, or 25%. Report both. Gross change shows disruption; net change shows the effect on final size.
A useful review says: “We began with 20 points, added eight, and removed three. Eighteen points were completed. Seven points remained in the final scope.” It then explains the business reasons for the changes.
Reporting only “scope grew 25%” cannot tell a stakeholder how much work was exchanged. A sprint could finish with the same point total it started with while containing substantially different issues.
Keep estimate changes separate from membership changes
The example deliberately holds estimates constant. Real sprints may include re-estimation, repeated removal and re-entry, or changes after work is completed.
Retain snapshots or a change history that identifies the issue, event time, prior value, and new value. For a custom ledger, choose a convention: additions enter at their estimate on entry, removals leave at their estimate on exit, and changes while included are recorded separately.
Under that convention:
Final scope = initial scope + additions − removals
+ estimate changes while included
Do not simply subtract two current totals and label the difference “added work.” That combines distinct causes and may lose the evidence needed to explain them.
Carryover needs a named denominator
In this example, seven points remain incomplete in the final scope. Relative to final scope, that is 7/25, or 28%.
Of the original commitment, SCOPE-4 is the four-point issue still incomplete and still included. SCOPE-3 was removed; it should not silently become “completed” or disappear from the commitment explanation.
Use the phrase “incomplete at sprint close” until you know where the work goes next. Moving it into the next sprint is a subsequent planning action. If your team calls all unfinished work carryover, state that definition beside the metric.
Sprint rollover FAQ
How do I report Jira carry over stories?
Start with the closed Sprint Report, list the issues Jira classified as incomplete, and record where each one went when the sprint closed. Count a story as carried over only if it moved into the next sprint; report items returned to the backlog separately. Preserve points or issue counts as they stood at close so later status or estimate changes do not rewrite the result.
Where is the Jira sprint rollover report?
Jira does not label a native report “Sprint Rollover Report.” Use the Sprint Report for the closed-sprint history, the burndown scope-change tables for additions and removals, and a saved-filter dashboard or export for the next-sprint assignment. The reconciliation sheet combines those views into committed, added, removed, completed, and carried-over totals.
Can JQL calculate historical sprint rollover by itself?
Not reliably. JQL can find issues associated with both sprint IDs, but current fields do not prove their status at the earlier close or distinguish every addition and removal event. Use JQL to define and review the issue set; use the Sprint Report or a frozen close snapshot for historical classification.
Scope change does not measure financial overrun
Eight added story points do not establish eight extra hours or a specific cost. To discuss effort or money, define a separate calculation using the relevant worklogs, estimates, dates, and costing assumptions.
An epic can include work outside the sprint, while a board can include issues outside a customer's contracted scope. Compare those boundaries before combining their totals.
The Jira estimated-versus-actual example shows how original effort, logged time, and remaining effort produce a point-in-time forecast. The four-sprint continuous-forecasting example carries those values forward while keeping scope events separate. TimePillar is an option to evaluate for related-issue time reporting; a time roll-up does not replace the sprint's scope history.
Bring three questions to the retrospective
Ask what entered after commitment, what left before close, and what prevented the remaining work from finishing. Use issue-level evidence, then decide whether to adjust intake, planning assumptions, or the next sprint's work.
Avoid treating the resulting percentages as individual productivity scores. Their first purpose is to make the team's planning and change decisions visible.
Next steps
- Need a cleaner baseline? Use the original estimate versus time spent guide before the next sprint review.
- Want the same check across projects and epics? Review TimePillar for Jira against one live delivery report.