A sprint report is a record of what a team planned for two weeks, what it finished, and what it did not. Most of it is written for the team rather than for you. Three parts of it are worth your attention, and the rest you can safely skim.
The vocabulary is the main barrier, and it is thinner than it looks. Here is what each term means in business language, followed by what to actually look at.
Key takeaways
- Story points are relative, not absolute: They measure size against other tasks, not hours. Comparing them between teams is meaningless.
- Velocity is a planning tool, not a performance score: Pushed as a target, it inflates.
- Carryover is the honest number: What was promised and not delivered, repeated sprint after sprint.
- Read three things: Carryover, the trend in scope added mid-sprint, and whether anything reached users.
The vocabulary, briefly
Sprint. A fixed working period, usually one or two weeks, with a list agreed at the start.
Story. One piece of work described from the user's side: "a customer can reset their password". The unit the team plans in.
Story points. A size estimate, relative rather than in hours. A five-point story is meant to be roughly five times a one-point story. Teams use relative sizing because humans are bad at estimating hours and better at estimating comparisons. Points from one team cannot be compared to another team's.
Velocity. Points completed per sprint, averaged. Used to forecast how much fits in the next sprint.
Burndown. A chart of work remaining against days elapsed. A healthy one falls steadily. A flat line that drops on the last day usually means everything was finished at once, which often means nothing was genuinely finished until the deadline forced it.
Carryover. Work planned for the sprint that did not get done and moves to the next one.
What to actually read
1. Carryover, sprint over sprint
This is the closest thing to a truth serum on a sprint report. It is the gap between what the team believed it could do and what it did, in the team's own numbers.
One sprint with heavy carryover is noise. Four sprints in a row where a third or more carries over means the planning is not connected to reality, and every date built on that planning is unreliable. It is rarely laziness; it is usually that the work is less understood than it appears, or that the team is being interrupted by something nobody is counting.
2. Work added after the sprint started
Most reports show this, sometimes as "scope added" or "unplanned work". It is the amount of work that arrived mid-sprint: urgent bugs, support escalations, a request from elsewhere in the business.
If this is consistently large, your team does not have a delivery problem, it has an interruption problem, and adding pressure to the roadmap will not help. This number is also the most common reason a capable team appears slow.
3. Whether anything reached users
Sprint reports measure completion against the team's definition of done, which may stop well short of a customer being able to use the thing. Ask directly, every sprint: what can a real user do now that they could not do before?
A run of sprints that complete cleanly while nothing reaches users means work is finishing into a queue rather than into production, and that queue eventually becomes a very large, very risky release.
What not to read too closely
Velocity as a score. If velocity is treated as a target, it rises without more work being done, because estimates drift upward. This is not usually deliberate; it is what happens to any number that gets used to judge the people producing it. Use velocity to plan, never to evaluate.
Individual point counts. A report broken down by person invites comparisons that the unit was never designed to support, and it discourages the collaboration that makes teams fast.
The five-minute version
If you have five minutes: look at carryover across the last four sprints, look at how much unplanned work arrived in each, and ask what reached users. Those three answers tell you whether you have a planning problem, an interruption problem, or a release problem, and those need completely different responses.
For the wider set of signals outside the sprint report, see how to tell if a project is really behind.
Ali Boran Gazel