Velocity is built from two numbers per sprint
Every velocity calculation comes down to two sums that Jira computes for each completed sprint. Atlassian's velocity chart documentation defines them like this:
- Commitment — “the total estimate of all work items in the sprint when it begins.”
- Completed — “the total completed estimates when the sprint ends.”
Velocity is then “the average of the total completed estimates over the last several sprints.” So velocity is really just the running average of the green bar. Everything else is about how those two sums are computed — and that's where the detail lives.
How commitment is counted
Commitment is a snapshot taken at sprint start. When you click Start sprint, Jira records the estimates of every issue then in the sprint and adds them up. A few rules follow from that:
- Issues added to the sprint before it starts are part of commitment.
- Issues added after the sprint starts are not — they're scope change, not commitment.
- Issues with no estimate contribute zero to commitment (which is exactly why unestimated work quietly distorts the picture).
This snapshot behaviour is the source of a lot of confusion later, because re-estimating an issue after the sprint started doesn't change that sprint's commitment number — the snapshot already happened.
How completed is counted
Completed is measured at sprint end: the sum of estimates for issues that are done. “Done” here means the issue is in a status mapped to your board's last column (the Done column). Two consequences matter:
- Work added mid-sprint and finished counts toward completed, even though it never counted toward commitment. This is why the green bar can occasionally be taller than the grey one.
- Work that's “basically done” but sitting in a status that isn't mapped to the Done column does not count. If you have a Released or Accepted status that isn't in your Done column, that work is invisible to velocity.
The Done-mapping trap: the native chart counts only what's in the board's Done column. Plenty of teams have more than one “finished” status, so their real completed work is higher than the chart shows. Aligning your board's column mapping with your actual Definition of Done is the single highest-impact fix for a velocity number that feels too low.
The estimation field decides the unit
Velocity isn't always in story points. The chart uses your board's estimation statistic, which is usually one of:
- Story Points — the default for most Scrum boards.
- Issue count — each issue counts as 1; useful for teams that don't estimate in points.
- Original time estimate or a custom numeric field — depending on board configuration.
The classic gotcha: a board configured for “Story Points” while the team actually estimates in the Story point estimate field (or vice-versa), so the chart reads an empty field and the bars come out near zero. Per Atlassian's notes on story-point calculation, the report sums whatever field the board is set to use — so if the bars look wrong, check that field first.
What's left out: sub-tasks
One rule surprises almost everyone: estimates from sub-tasks are not included in the native velocity chart. Only standard issue types are counted. If your team puts its estimates on sub-tasks rather than on the parent story, the native chart will systematically understate your velocity. The options are to estimate at the story level, or to use a gadget that lets you opt sub-tasks in.
A worked example
Take one sprint. At start, four stories are in it:
| Issue | Estimate | At sprint start? | Done at end? |
|---|---|---|---|
| STORY-1 | 5 | Yes | Yes |
| STORY-2 | 8 | Yes | Yes |
| STORY-3 | 3 | Yes | No |
| STORY-4 | 5 | Yes | No |
| STORY-5 (pulled in mid-sprint) | 2 | No | Yes |
- Commitment = 5 + 8 + 3 + 5 = 21 (the four issues present at start; STORY-5 is excluded).
- Completed = 5 + 8 + 2 = 15 (everything done at end, including the mid-sprint STORY-5).
So this sprint shows a 21-point grey bar and a 15-point green bar — a say/do ratio of about 71%. Note how the pulled-in STORY-5 lifts completed without ever touching commitment: that asymmetry is by design.
Why your reports sometimes disagree
A frequent support question is “why doesn't my velocity chart match my sprint report (or a JQL sum of story points)?” The usual culprits:
- Re-estimation after start. The velocity chart's commitment is frozen at sprint start; a live JQL sum reflects today's estimates. If anyone re-pointed an issue mid-sprint, the two will differ.
- Unmapped statuses. An issue in a status not mapped to any board column may be excluded from the calculation entirely.
- Scope changes. Items added or removed during the sprint shift completed but not commitment.
- Sub-tasks. A JQL sum that includes sub-task points won't match the chart, which ignores them.
None of these are bugs — they fall straight out of the snapshot-and-mapping rules above. But they explain why a single “true” velocity number is harder to pin down than it looks.
Measuring velocity your own way
Because the native rules are fixed, teams whose process doesn't match them — multiple Done statuses, estimates on sub-tasks, a non-default estimation field — end up with a velocity that doesn't reflect reality. Velocity Chart for Jira recomputes the same committed-vs-completed model but lets you set the parts the native report locks down: it reconstructs commitment from the real sprint scope at start (from the sprint-field change history), lets you choose exactly which statuses count as Done, pick the estimation field, and optionally include sub-tasks — then shows it all on a dashboard, on company- and team-managed boards alike. The maths is the same; you just get to define the inputs.
Frequently asked questions
How is sprint velocity calculated in Jira?
For each sprint, commitment is the total estimate of work in the sprint at start, and completed is the total estimate done by sprint end. Velocity is the average of the completed values over the last several sprints.
Does work added mid-sprint count toward commitment?
No. Commitment is frozen at sprint start. Work added later doesn't raise commitment, but if it's finished it raises completed — which is why completed can sometimes exceed commitment.
Are sub-tasks included in the velocity chart?
No — the native velocity chart excludes sub-task estimates and counts only standard issue types. Teams estimating on sub-tasks will see velocity understated unless they use a tool that can optionally include them.
Why don't my velocity chart and sprint report agree?
Usually issues re-estimated after sprint start (commitment is a start-of-sprint snapshot), issues in unmapped statuses, scope changes during the sprint, or a JQL sum that includes sub-task points the chart ignores.
Velocity measured the way your team works
Choose your Definition of Done, your estimation field and sub-task handling — then see committed vs completed on any dashboard with Velocity Chart for Jira.
Get it on Marketplace →