Sprint Tracking Report
Last updated: October 27, 2026
The Sprint Tracking report shows how a team's Jira sprints went: what was planned, what was finished, what was added mid-sprint, and what was still open, blocked, or in review when the sprint ended. It requires a Jira integration.
Why it matters
Sprint Tracking measures planning predictability. Planning accuracy shows whether the team finishes what it commits to, and the breakdown shows why it didn't: scope added mid-sprint, work that rolled over, or issues stuck in review or blocked. Tracking these sprint over sprint helps a team right-size its commitments.
How it works
Which issues belong to a sprint. Span reads each Jira sprint and every issue's sprint history. An issue counts in a sprint when someone added it before the sprint ended and didn't remove it before the sprint started. Span ignores any stretch where an issue sat in a sprint for less than one day, so quick drag-in, drag-out moves don't count. Jira epics and initiatives never count.
Planned or unplanned. An issue is planned when it was in the sprint at the start or added within the first 24 hours. Anything added later is unplanned.
Final state. For each issue, Span takes its status, story points, and assignee at the earliest of: the sprint end date, the date someone completed the sprint, or the time someone removed the issue from the sprint.
Planning accuracy is the report's main metric, shown in issues or story points:
Issues Planning Accuracy = planned issues completed ÷ planned issues
Estimate Planning Accuracy = planned story points completed ÷ planned story points
Completed means the issue reached a status in Jira's Done category before the sprint ended. A higher score means the team finishes what it commits to; lower scores point to scope creep, underestimation, or blockers. When a view covers several sprints, Span pools all their issues and divides the totals rather than averaging each sprint's percentage.
Sprint breakdown table. Each row shows the selected sprint's value and a trend across recent sprints:
Row | What it shows |
|---|---|
Planned Completed (%) | Planned Completed ÷ Total Completed: the share of finished work that was planned. This is different from planning accuracy, which divides by everything that was planned |
Total Completed | All issues or points completed in the sprint, planned or not |
Planned Completed | Planned issues or points completed by sprint end |
Unplanned Completed | Issues or points added a day or more after the start and completed |
Rollover | Issues not done at sprint end that were still in the sprint when it ended, planned or unplanned, wherever they went next |
Blocked | Issues in a status named "Blocked" at sprint end |
In Progress | Issues in a Jira In Progress category status at sprint end |
In Review | Issues in a status named "In Review" at sprint end |
Investment Effort | FTE-days invested during the sprint (needs investment reporting set up) |
Issue cycle time | The average time issues done in the sprint spent in In Progress statuses |
Setup
Connect Jira. The Sprint Tracking menu appears only for organizations with Jira.
For each team, go to Settings → Team Settings, open the Sprints card, and turn on Enable Sprint Tracking. Add rules to include the Jira boards or projects the team uses. Sprint Tracking supports Scrum boards only.
Optionally turn on Enable Story Points to make points the team's default unit.
Open Insights → Productivity → Sprint Tracking, pick the team, and choose a sprint from the sprint selector.
Display settings are personal and don't change what others see:
Setting | What it does |
|---|---|
Issues Unit | Switch between issues and story points |
Include issues assigned to non-team members | On by default. Turn off to keep only issues assigned to team members |
Investment Framework | Pick the investment view for the investment breakdown, when more than one is available |
Show in progress and in review statuses in planning accuracy | On by default. Adds In progress and In review bars to the planning accuracy chart. It doesn't change the planning accuracy number |
Investment breakdown. With investment reporting set up and the Investment permission, a breakdown below the table shows how sprint work split across your investment categories.
Exploring issues. Click a row in the breakdown table to open the issue drawer: the issues in that category with links to Jira, a breakdown by assignee, each issue's cycle time, and a link to the full sprint issue list.
Permissions. Viewing Sprint Tracking needs the Issue Tracking permission. The investment breakdown needs the Investment permission. Turning on Sprint Tracking for a team needs the Manage Team Settings permission for that team. If you can't see data for some teams or people, the report shows which access is missing.
Things to know
Worked example: a sprint starts with 12 planned issues. The team finishes 6 of them and also finishes 2 issues added on day 4. Planning accuracy is 6 ÷ 12 = 50%. Planned Completed (%) is 6 ÷ (6 + 2) = 75%. Total Completed is 8.
Removed issues stay in the plan: a planned issue removed mid-sprint still counts in the planned total, with its status at removal. If it wasn't done, it lowers accuracy. An issue removed before the sprint started doesn't count.
Done after the sprint ends doesn't count for that sprint.
Unassigned issues drop out: sprint totals include only issues that had an assignee at sprint end. The issue drawer still lists unassigned issues, so it can show more issues than the chart counts.
Rollover doesn't check where the issue went: an unfinished issue left in a closed sprint, moved to the backlog, or moved to the next sprint all count. An issue that rolls over twice counts once in each sprint.
Status names must match: Blocked counts only a status named exactly "Blocked", and In Review only a status named "In Review" (any capitalization). Jira flags don't count. If your review status sits in Jira's In Progress category, which is Jira's default, the issue appears in both In Progress and In Review.
Story points use each issue's estimate as of sprint end, not sprint start. Issues without points add 0.
Why accuracy is lower than Jira's sprint report: Span keeps planned issues removed mid-sprint, counts only issues done before the sprint ended, and leaves out unassigned issues. Span also gives a 24-hour grace period for planned issues, which Jira doesn't.
Kanban teams: Kanban boards have no sprints. Use the Issue Lifecycle report for continuous flow metrics.
Tips. Watch the trend charts rather than single sprints. High Blocked or In Review counts at sprint end point to review and dependency problems. A consistently high rollover count suggests over-commitment, and a high share of unplanned completed work suggests reactive work or backlog gaps. Read the investment breakdown to check whether sprint effort matches your priorities.
Related articles
Total Story Points Completed Report
Need help?
Contact your Span account team or reach out to support@span.app.