Sprint Report

Reports

Overview

The sprint report is a complete record of what happened in a sprint — what was committed, what was completed, what carried over, and whether the sprint goal was met. It is generated automatically when a sprint is closed and serves as the primary input for the sprint retrospective.

The report is immutable once the sprint is closed — it captures the state of the sprint at the moment of close. Subsequent changes to stories (moved to a new sprint, re-estimated) don't alter the historical report.

Accessing sprint reports

1Open the Sprint List from the project sidebar
2Filter by Closed status to find past sprints
3Click the sprint name to open the sprint detail view
4Click the Report tab

You can also access the current sprint's in-progress report from KPIs & Reports → Sprint Report before the sprint closes. The in-progress version updates in real time.

Sprint report metrics

MetricDescription
CommitmentTotal story points committed at sprint start. Set when the sprint was started — stories added after start are tracked separately.
CompletedStory points in Done at sprint close. This is the sprint's velocity contribution.
Completion rateCompleted ÷ Commitment × 100. The most direct measure of sprint predictability.
Carry-over pointsPoints from stories that were not completed and moved to the next sprint or backlog.
Stories completedCount of stories in Done at sprint close.
Stories carried overCount of stories moved out of the sprint without completing.
Sprint goal outcomeMet or Not Met, as assessed by the team at sprint close.
Defects raisedNumber of defects created during the sprint — a quality indicator.
Defects closedNumber of defects resolved during the sprint.

Completed and incomplete story lists

Below the summary metrics, the report shows two story lists:

  • Completed stories — every story in Done at sprint close, with title, assignee, points, and story type. Stories added mid-sprint are marked "Added after start".
  • Incomplete stories — stories that were in the sprint but not in Done at close. Each shows where it was moved (backlog, next sprint, or deleted) and its status at the time of close. This list is the most important part for retrospectives — understanding why each story didn\'t finish drives process improvement.

Understanding completion rate

RateDiagnosisNote
90–100%Strong predictability. Team is committing and delivering consistently.If this is every sprint, check whether the team is sandbagging (under-committing to guarantee completion). A small amount of carry-over is normal and healthy.
75–89%Acceptable. Most of the commitment was delivered. Small carry-over is normal.Review what carried over and why. If it's always the same type of story (large, late-arriving, dependent), address the root cause.
50–74%Sprint was significantly over-committed, disrupted, or had major blockers.This warrants a dedicated retrospective topic. Identify whether the cause was planning (wrong estimates), execution (blockers), or external (scope injected mid-sprint).
Below 50%Sprint failed to deliver the majority of its commitment. Systemic problem.Immediate retrospective. Something is fundamentally broken — estimation, scope management, team capacity, or external dependencies. Do not continue at this pace without intervention.

Using the report in retrospectives

The sprint report gives retrospectives a factual foundation instead of relying on memory. Before your retrospective:

1Pull up the sprint report and share it with the team — open it on a screen or export to PDF/CSV
2Start with the sprint goal outcome: was it Met or Not Met, and does the team agree with that assessment?
3Review the incomplete story list one by one — for each, ask: was this a planning problem (wrong estimate, dependency not identified) or an execution problem (blocker, scope change)?
4Look at the completion rate trend over the last 3–5 sprints using the Velocity Chart — is predictability improving or degrading?
5Review the defects raised count — a high number relative to stories completed may indicate quality is being sacrificed for throughput
The most useful retrospective question the sprint report surfaces is: "Did the same kinds of stories carry over as last sprint?" Carry-over patterns are process signals. If large stories always carry over, the team needs to split them more aggressively. If dependency-blocked stories always carry over, dependency identification needs to happen earlier in planning.

Exporting the sprint report

Click Export from the sprint report to download:

  • PDF — formatted summary suitable for sharing with stakeholders or archiving
  • CSV — full story-level data including all metrics, useful for building custom trend analyses in a spreadsheet

Troubleshooting

I can't find the sprint report for a past sprint

Sprint reports are accessed from the Sprint List. Open the Sprint List, filter by Closed status, click the sprint, and open the Report tab in the sprint detail view. Reports are stored indefinitely.

The completion rate is wrong — it shows 100% but we know some stories didn't finish

Stories moved to a future sprint before the sprint was closed are counted as carry-over. Stories that were in Done at the time of close count as completed. If a story was manually moved to Done after close, it won't affect the closed sprint's report.

The report doesn't show which stories were added mid-sprint

The report has a "Scope changes" section that lists stories added after the sprint was started. Look for the "Added after start" label on individual story rows in the completed and incomplete story lists.

I want to export multiple sprint reports at once

Individual sprint reports can be exported to CSV from the sprint detail view. For a multi-sprint summary, use the Velocity Chart export — it includes completion rate and points delivered per sprint across your selected range.

The sprint goal outcome shows "Not assessed" even though we marked it

The goal outcome is recorded during the sprint close flow. If the sprint was closed without going through the close dialog (e.g. via an API or admin action), the goal outcome may not have been set. Open the closed sprint's detail view and look for a "Set goal outcome" option to update it manually.