"How much work did we plan, and how much actually got delivered?"
It's the first question anyone asks in a retro, and the last one a project manager can answer quickly.
Jira Software has three reports that get close, each measuring something slightly different, but the trick is… none of them covers more than one board.
If you're short on time
- The velocity chart compares commitment against completed in story points, per sprint, for one board.
- The sprint report shows the same thing for one sprint, plus scope change.
- The time tracking report compares Original estimate against time spent, in hours, per project (but it's scheduled for retirement.
- Nothing native rolls planned vs actual data up across multiple projects or multiple teams. That's where exports, Google Sheets, BI tools or third party apps come in.
First: which "planned" do you mean?
Two different questions hide behind the same phrase, and picking the wrong report is usually just picking the wrong unit.
Scope. Did we deliver the work items we said we would? Measured in story points or issue count. This is the sprint commitment question, and it's what agile reports are built around. It's also what most project management conversations actually run on: are we delivering what we said, at a pace we can plan around?
Effort. Did the work take as long as we estimated? Measured in hours, original estimate against time spent. This is the estimation accuracy question, and it needs people to log time.
Teams that only track story points can answer the first and never the second. That's fine until someone asks why a project cost twice what was quoted.
The native agile reports
A quick note before we start: the reports below are what you get in company-managed spaces. Team-managed spaces show a smaller set.
Velocity chart
The closest thing Jira has to a planned vs actual chart. Two bars per sprint: Commitment (sum of estimates on work items in the sprint when it started) and Completed (sum of estimates for items done by the time it closed).
Three things worth knowing before you trust your velocity report:
- It shows your last 7 sprints, and you can't change that number.
- It's tied to one Scrum board. Not a dashboard gadget, not cross-board.
- Commitment excludes work added after the sprint started, and items sitting in a status that isn't mapped to a board column count as zero.
That last point catches people out. If your team's estimates don't match the commitment sum, check whether a work item was added late or sits in an unmapped status.
Sprint report
Same comparison, one sprint at a time, with the detail the velocity chart hides: exact issues completed, issues not completed, and work added after the start — marked with an asterisk.
This is where scope creep shows up. If sprint after sprint has a long asterisk list, the problem isn't team performance, it's that sprint commitments aren't being treated as commitments.
Burndown chart
Tracks sprint progress day by day against the ideal line. Useful while a sprint is running, less so afterwards — it shows the team's progress through the week, not how the plan compared to reality.
Time tracking report
The effort side. It lists work items with original estimate, remaining estimate and time spent, plus an accuracy column, so you can see what's ahead of or behind the original plan.
❗Before you lean on it: Atlassian has scheduled this report for retirement, along with the User Workload and Version Workload reports. At the time of writing it still opens, banner and all, but its days are numbered, so don't build a process around it.
Two more limits: it's scoped to a version inside a single Jira project, and there's no person in it at all.
Where the native reports stop
One board, one project. Everything above is board- or project-bound, and none of it can be added to a Jira dashboard for an at-a-glance read on your project's progress. Multiple teams on a program increment, or one PI planning cycle spanning multiple boards, has no native roll-up.
No export. The velocity chart and sprint report don't export. If you want the actual data in Google Sheets or your BI tools, you're reading numbers off a screen or pulling them through the API. Apps generally solve this — exports to Excel or CSV with filters preserved are table stakes, ours included.
Story points and hours never meet. Planned work in points, actual time in hours — Jira won't reconcile them for you.
Sub-tasks complicate everything. Estimates on sub-tasks don't roll up into the parent's own fields, so what counts as "planned" depends on which issue type you estimated.
No history you control. Commitment is captured by Jira at sprint start. If you want a stable baseline of your own, an automation rule that copies story points into custom fields when a sprint starts is the usual workaround — then JQL gives you a date range comparison Jira won't.
Getting planned vs actual across multiple projects
Three routes, in increasing order of effort:
- Export and combine. Pull sprint data per board, drop it into Google Sheets, create one view manually. Fine quarterly, miserable weekly.
- Feed a BI tool. The REST API gives you sprint and worklog data; your BI stack does the rest. Good if you already have one.
- Add an app. Third party apps on the Marketplace cover the cross-board and cross-project gap most teams hit first.
I work on one of these, so weigh this accordingly.
Planyway's planned vs tracked report compares planned time against logged time across as many Jira projects as you connect, with the deviation in percent, grouped by project, epic, work item, person or date over any range.
➡️ Try Planyway free
It answers the effort question rather than the scope one — where estimates were wrong, not whether you hit the sprint commitment. The velocity chart still does that job better. What you get instead is one view across projects, a range that isn't locked to seven sprints, and the people dimension Jira's reports leave out.
Making the numbers mean something
A planned vs actual report is only as honest as the habits behind it.
Don't re-size stories mid-sprint. It's the fastest way to make velocity data meaningless.
Look at the trend, not the sprint. One sprint at 60% tells you about that fortnight. Six sprints averaging 70% tells you your planning is systematically optimistic, which is a far more useful finding.
Separate scope change from bad estimation. The sprint report distinguishes them: work added after the start is a scope problem, work committed and unfinished is an estimation problem. They need different conversations.
Decide what you'll do with it. Valuable insights that nobody acts on stop getting produced. If the report doesn't change the next sprint's scope or the next quarter's estimates, you're collecting data for its own sake.
Share it with the team. Planned vs actual used to grade people produces better-looking numbers and worse plans. Used to improve estimates, it produces better plans.
The short version
Jira gives you a decent planned vs actual picture inside one board: the velocity chart for the trend, the sprint report for the detail, the time tracking report for hours. Push past one board or one project and you're exporting, scripting, or installing something.
Pick the question first — delivery predictability or estimation accuracy — and then the report. Most of the frustration with Jira's agile reports comes from asking one of them a question it was never built to answer.
