Easy Tech TutsHow to See or Track Previous Sprint History in Jira Easily 2026
By Impran M NLast checked against official docs
Once a sprint closes in Jira, its board view empties out, but the data isn't gone. It moves to Reports, where velocity, completed work, and the day-by-day burndown of a finished sprint live.
Many teams never open this section, since nothing on the board points you there directly. This guide covers navigating from your project's board to its sprint reports, reading a burndown chart correctly, and using the detailed event log underneath it to see exactly when each issue moved, completed, or got pulled from the sprint.
Before you start
- A Scrum project. Burndown Chart, Sprint Report, and Velocity Chart are Scrum board reports; Kanban boards don't run sprints, so they use Cumulative Flow and Control Chart instead.
01Open your board and find the Reports tab
From your project, open its board and look at the row of tabs across the top: Summary, Timeline, Backlog, Active sprints, List, Calendar, and Reports. Reports is where all historical sprint data lives, separate from Active sprints, which only shows what's currently in progress or not yet started.
If Active sprints looks empty with a prompt to plan work in the backlog, that just means no sprint is running right now. History is still sitting under Reports.
02Select a past sprint from the Burndown Chart
Inside Reports, choose Burndown Chart, then use the sprint dropdown at the top (labeled with the current or most recent sprint name) to switch to any earlier sprint your project has run. A second dropdown next to it toggles how work is measured, typically Issue count or Story points, which changes what the vertical axis represents.
The chart's legend also marks Non-Working Days as hatched bands; uncheck Show Non-Working Days if you'd rather see a plain, continuous guideline. Picking an older sprint reloads the chart with that sprint's own data, no separate archive to dig through.
03Read the chart correctly
The burndown chart plots issue count (or story points) remaining against time across the sprint's date range. A gray guideline shows the steady pace needed to finish everything by the sprint's end date.
The colored line tracks what happened: work completed, added mid-sprint, or left over. A sudden jump upward usually means scope was added after the sprint started.
A flat stretch of several days with no drop points to a period where nothing was completed. Both are worth raising in a retrospective, not just noting in passing.
04Check the detailed event log below the chart
Scroll past the chart to a table logging every event tied to the sprint by exact date and time: sprint start, sprint end, and each issue's movement in or out. Each row lists the issue keys involved, the event type, and columns for increase, decrease, and running remaining count, an audit trail of what happened and when, down to the minute. Check this table when a sprint's outcome looks confusing from the chart alone; it names exactly which ticket caused a jump or a stall.
05Cross-reference with the Sprint Report and Velocity Chart
Burndown Chart is one of three reports worth checking together. Sprint Report lists which issues were completed versus not completed by the sprint's end; it carries its own grey-and-red progress line too, not just a list.
Velocity Chart tracks completed work across multiple sprints, so you can see whether your team's throughput is trending up, down, or holding steady. Looking at all three for the same sprint gives a fuller picture than any single chart alone, especially when explaining a missed sprint goal to stakeholders.
When it doesn't work
Story points in the burndown or velocity chart don't match what's estimated on subtasks
Why: Both charts only count story points on the parent issue. Subtask estimates are excluded from the calculation entirely.
Fix: Estimate story points at the story or task level, not on subtasks, if you want these reports to reflect that work.
Burndown Chart, Sprint Report, or Velocity Chart aren't available on a board
Why: The board is a Kanban board. These three reports are Scrum-only, since Kanban boards have no sprints to report on.
Fix: Check the Reports tab on a Scrum board instead, or use Cumulative Flow and Control Chart if the board is genuinely Kanban.
A sprint's data looks incomplete or missing in Reports
Why: The Burndown Chart only includes issues matching the board's current saved filter. If that filter changed after the sprint ran, issues from the sprint can drop out of the report even though the sprint itself still exists.
Fix: Check the board's saved filter under board settings and confirm it still matches the issues that were part of that sprint.
Frequently asked questions
Where do I find data for a sprint that already ended in Jira?
Open your board and go to the Reports tab, not Active sprints, which only shows current or upcoming work. Reports holds Burndown Chart, Sprint Report, and Velocity Chart for every past sprint.
What's the difference between the Burndown Chart and the Sprint Report?
Burndown Chart is a trend line of work remaining over time, with a detailed event log underneath. Sprint Report lists exactly which issues were completed versus not completed when the sprint closed, though it includes its own grey-and-red progress line too, so the two overlap more than their names suggest.
Why does the burndown line jump upward partway through a sprint?
That means scope was added mid-sprint, a new issue pulled in after the sprint started. Check the event log below the chart to see exactly which issue caused the jump and when.
Can I compare velocity across several past sprints at once?
Yes. The Velocity Chart plots completed story points or issue counts across multiple recent sprints in one view, the best report for spotting a trend instead of reading a single sprint's outcome.
Does switching the Burndown Chart's measurement from Issue count to Story points change historical data?
No, it only changes how the same historical data is displayed. The underlying events, what was completed, added, or removed and when, stay identical regardless of which unit you view the chart in.
How do I use this history instead of just reviewing it after a bad sprint?
Pull up the last three to five sprints' reports together during backlog grooming or sprint planning, not only after something's gone wrong. If velocity has been declining for three sprints running, or the same kind of ticket keeps getting pulled mid-sprint, that's a planning signal worth acting on before the next sprint starts.
Sources and last check
Click path and screens come from a walkthrough recorded in 2026. The report names, chart legend, and event-log structure matched what's shown on screen. Re-checked against Atlassian's official Jira Cloud documentation in September 2026, which surfaced two constraints this guide hadn't mentioned: these three reports are Scrum-only (Kanban boards use different reports), and subtask story points are excluded from both the burndown and velocity calculations.
About the author
Impran M N
I've been hooked on technology for as long as I can remember — especially the new tools and AI apps that seem to land every other week. Easy Tech Tuts is where I write up whatever I've just worked out: I do the task in the real product, record the screen, and turn it into the guide I wish I'd found first.
