Team velocity is the number of story points a team completes in a sprint. To calculate it, add up the points of every item that met your Definition of Done by the end of the sprint, then average that number over the last 3 to 6 sprints to get a planning velocity. Unfinished work counts as zero.
That is the whole formula. The useful part is everything around it: which sprints to include, how to adjust for holidays, how to turn velocity into a release forecast without promising a single date, and how to keep the number from being misused. If you want to skip the arithmetic, paste your last few sprints into the free sprint velocity calculator and it does the averages and forecast for you.
What is velocity in agile?
Velocity measures how much estimated work a team actually finishes per iteration. It is a planning input, not a productivity score. The Scrum Guide does not mention velocity at all; it is a practice teams adopted because it answers one practical question: "Based on what we have really finished lately, how much should we plan for next?"
Two things make velocity work:
- Relative estimates that stay consistent. If your team's idea of a "5" shifts over time, velocity drifts with it. (See calibrating story points for how to catch that.)
- A strict Definition of Done. A story that is coded but untested is not done, so it contributes nothing that sprint.
Because both of those are specific to one team, a velocity of 30 means nothing outside that team. More on that below.
The agile velocity formula
Sprint velocity = sum of story points for items Done at sprint end
Planning velocity = (velocity of last N sprints) / N, where N is usually 3 to 6.
Rules that keep the number honest:
- Count a story only in the sprint where it reached Done. If it carries over, it counts in full in the sprint it finishes, not split across both.
- Count points as estimated before the sprint started. Do not re-point a story upward at sprint end because it was harder than expected (the full reasoning is in re-estimating stories mid-sprint).
- Decide once whether bugs, spikes and chores get points, and stick to it. Either choice works; switching between them breaks the trend.
- Use the same sprint length. If you change from 2 weeks to 3, start a new baseline.
Worked example: 6 sprints
A team of five runs 2-week sprints. Here is their history, including a 3-sprint rolling average:
| Sprint | Committed | Completed (velocity) | 3-sprint rolling avg | Notes |
|---|---|---|---|---|
| 1 | 32 | 28 | – | |
| 2 | 33 | 34 | – | |
| 3 | 30 | 22 | 28.0 | Public holiday + one person out 4 days |
| 4 | 31 | 31 | 29.0 | |
| 5 | 32 | 30 | 27.7 | Production incident on day 6 |
| 6 | 33 | 33 | 31.3 |
From this table:
- Total completed: 28 + 34 + 22 + 31 + 30 + 33 = 178 points
- Average velocity: 178 / 6 = 29.7 points per sprint
- Median: 30.5 (the middle of 22, 28, 30, 31, 33, 34)
- Range: 22 to 34
- Latest rolling average: 31.3
Which number do you plan with? For the next sprint, the rolling average (31) or median (30) is fine if nothing unusual is coming. For anything longer than a sprint, use a range, not a single figure.
Notice sprint 3. You might be tempted to throw it out as an outlier. Don't delete it; explain it. Holidays and absences happen every quarter, so a history with all of them removed will be optimistic. The better fix is to adjust for capacity, which is the next section.
Capacity-adjusted velocity (holidays, PTO, team changes)
Raw velocity assumes every sprint has roughly the same people available. When that's not true, convert velocity into points per available person-day, then multiply by the capacity you actually have next sprint.
Using the same team (5 people, 10 working days, so 50 person-days at full strength):
| Sprint | Person-days available | Completed | Points per person-day |
|---|---|---|---|
| 1 | 48 | 28 | 0.58 |
| 2 | 50 | 34 | 0.68 |
| 3 | 35 | 22 | 0.63 |
| 4 | 50 | 31 | 0.62 |
| 5 | 46 | 30 | 0.65 |
| 6 | 50 | 33 | 0.66 |
| Total | 279 | 178 | 0.64 |
Sprint 3 looked like a bad sprint in raw terms (22 points), but per available person-day it was right in line with the others. The team didn't slow down; there were fewer of them.
Now plan the next sprint. It has a 2-day holiday for everyone (5 people x 8 days = 40 person-days) and one developer is out 3 more days, leaving 37 person-days.
Forecast = 37 x 0.64 = 23.7, so plan around 23 to 24 points, not the 30 the raw average suggests.
A few practical notes:
- Count person-days for people who build and test the product. Don't count a Scrum Master or a manager who rarely picks up stories unless they usually do.
- Subtract recurring known load (on-call rotation, support duty) the same way every sprint, or not at all. Consistency matters more than precision.
- When someone new joins, don't count them at full capacity for the first sprint or two. Onboarding pulls time from existing members too.
- If the team composition changes permanently (two people leave, three join), the old points-per-day figure becomes a rough guide only. Build a fresh baseline over 3 sprints.
Forecasting a release with a range, not a date
The classic approach is "remaining points / velocity = sprints left." It produces a single date that will almost certainly be wrong, because velocity varies sprint to sprint. Use your history to give a range instead.
Say the team has 220 points left in the release backlog. Sort their six velocities (22, 28, 30, 31, 33, 34) and take:
| Scenario | Velocity used | Sprints needed | Weeks (2-week sprints) |
|---|---|---|---|
| Pessimistic: average of the 3 slowest sprints | 26.7 | 220 / 26.7 = 8.2, so 9 | 18 |
| Expected: overall average | 29.7 | 220 / 29.7 = 7.4, so 8 | 16 |
| Optimistic: average of the 3 fastest sprints | 32.7 | 220 / 32.7 = 6.7, so 7 | 14 |
Always round up: you can't ship in 0.4 of a sprint.
What to tell stakeholders: "Most likely 7 to 9 sprints, so 14 to 18 weeks, assuming the scope stays at 220 points." The absolute min/max (22 and 34) would give 7 to 10 sprints. That is technically honest but usually too wide to be useful, which is why averaging the slowest and fastest three works well as a middle ground.
Two adjustments experienced teams make:
- Account for scope growth. Backlogs grow as you learn. If the release backlog has grown by around 10 points a sprint historically, your net burn rate is velocity minus 10. Track this; it's often the biggest source of missed dates.
- Re-forecast every sprint. A forecast is a snapshot. Update the range after each sprint and show the trend. A range that narrows as you approach the release is what builds trust.
The sprint velocity calculator runs this range forecast from your own numbers if you'd rather not maintain a spreadsheet.
How to calculate velocity in Jira
Jira calculates velocity for you on Scrum boards (Kanban boards don't have sprints, so no velocity chart).
- Open your Scrum board.
- Go to Reports in the board sidebar.
- Choose the Velocity Chart (called the Velocity Report in some newer Jira Cloud views).
- Each sprint shows two bars: Commitment (estimate total at sprint start) and Completed (estimate total of issues Done when the sprint closed).
How to calculate average velocity in Jira: depending on your Jira version, the report may display an average directly. If it doesn't, add up the Completed values for the sprints shown and divide by the number of sprints. For example, Completed values of 28, 34, 22, 31, 30 and 33 give 178 / 6 = 29.7.
Things that trip people up in Jira:
- The estimation statistic must be Story Points. Check board settings under Estimation. If it's set to issue count or original time estimate, the chart measures that instead.
- Issues added mid-sprint show up in Completed but not in Commitment, so Completed can exceed Commitment. That's scope added, not the team "beating" its plan.
- Changing story points mid-sprint shifts what's counted. The Sprint Report flags estimate changes; check it before trusting a sprint's numbers.
- Unfinished issues moved to the next sprint count zero in the closed sprint and full value in the sprint where they're completed.
- Sub-task estimates are generally not rolled into velocity. Estimate at the story level.
Jira doesn't send estimates in from planning poker by itself unless you use a connected add-on. Many teams estimate in a separate tool and type the agreed number into the Story Points field. The Jira planning poker guide covers that workflow.
Velocity by epic
Jira's Velocity Chart is per sprint, not per epic. To see velocity by epic, use the Epic Report to see completed versus remaining points for one epic, or filter completed issues by epic and sprint and sum the points. Dividing points completed on an epic by the number of sprints the team worked on it gives an epic burn rate. That's useful for answering "at the current pace, when does this epic finish?", especially when the team splits its time across several epics.
Velocity chart for multiple teams
If you run several teams, you can put their velocities on one chart. Just be clear about what that chart is for.
Good uses: showing each team's own trend over time (one line per team, each judged against itself), and summing expected capacity for program-level planning when teams share a common estimating baseline.
Bad uses: ranking teams, or concluding that the team at 45 points is more productive than the team at 25. Each team's points are sized against its own reference stories. One team might have a smaller "point" or count bugs where the other doesn't. The numbers don't share a unit.
If leadership needs cross-team comparability, that's a different problem with real trade-offs. See standardizing estimation across enterprise teams, which covers SAFe-style normalized story points and their downsides.
Why you shouldn't calculate individual velocity in Scrum
People search for "how to calculate individual velocity in Scrum" because a manager asked for it. You can technically do it by summing the points of stories assigned to each person. Here's why you shouldn't:
- Stories are team work. One name sits on the ticket, but reviews, pairing, testing and unblocking come from others. Individual velocity gives all the credit to the assignee.
- It punishes helping. The senior engineer who spends half the sprint unblocking others shows low "velocity."
- It invites gaming. People grab easy, well-pointed stories and inflate estimates on their own work. Goodhart's law applies: once the measure becomes a target, it stops measuring anything.
- Points weren't designed for it. The team estimates relative size together. Splitting that up by person turns a shared sizing tool into a performance metric.
If you need to understand individual contribution, use conversations, peer feedback and observation. If you need capacity per person for planning, use available days, as in the capacity-adjusted example above.
Team velocity metrics worth tracking alongside velocity
Velocity alone hides a lot. These are cheap to track and catch problems early:
| Metric | How to calculate | What it tells you |
|---|---|---|
| Say/do ratio | Completed / Committed per sprint | Whether planning is realistic. Consistently under 80% means overcommitting |
| Velocity range | Min and max of last 6 sprints | Predictability. A narrowing range is a better sign than a rising average |
| Carry-over rate | Points carried to next sprint / Committed | Stories are too big or work is started too late |
| Scope added mid-sprint | Points added after sprint start | Interruptions and planning gaps |
| Work mix | % of points on features vs bugs vs tech debt | A flat velocity with rising bug share is a quality warning |
Velocity anti-patterns (and fixes)
| Anti-pattern | Why it hurts | Fix |
|---|---|---|
| Setting velocity targets ("get to 40 next quarter") | Teams inflate estimates; points lose meaning | Track predictability (range, say/do), not growth |
| Comparing teams' velocities | Different baselines, so comparison is meaningless and breeds gaming | Compare each team to its own history |
| Counting partially done stories | Inflates velocity, hides unfinished work | Zero points until Done; split stories that are too big |
| Re-pointing stories at sprint end | Rewrites history; velocity stops being predictive | Keep the original estimate; log the surprise for the retro |
| Planning with your best sprint | Sets up overcommitment | Use the average or median; forecast with a range |
| Deleting "bad" sprints from history | Forecasts become optimistic | Keep them; use capacity adjustment instead |
| Pointing spikes and meetings to "show work" | Velocity rises with no extra delivery | Timebox spikes; leave ceremonies out of points |
| Steady velocity increase with no team change | Usually estimate inflation, not improvement | Run a blind re-estimation of old stories |
Estimating team velocity for a new team
A brand-new team has no history. Some options, from weakest to strongest:
- Borrow another team's velocity. Avoid this; their points aren't your points.
- Capacity-based guess. Estimate a sprint's worth of backlog items, have the team commit to what they believe fits, and call that sprint 1's forecast.
- Run three sprints, then measure. Most teams get a usable average after 3 sprints and a stable range after 5 or 6. Until then, give stakeholders wide ranges and say why.
Velocity becomes reliable faster when estimates are consistent. Running planning poker for every story, with votes hidden until reveal, keeps the loudest voice from setting every number. Alignlee's free planning poker also lets each voter attach a confidence level, which flags stories the team is unsure about before they make it into the sprint.
FAQ
How do you calculate team velocity?
Add up the story points of all items that met the Definition of Done in a sprint; that's the sprint's velocity. Then average the last 3 to 6 sprints to get the velocity you plan with. For example, 28, 34, 22, 31, 30 and 33 points average 29.7.
What is the agile velocity formula?
Velocity = sum of completed story points per sprint. Planning velocity = total completed points over N recent sprints divided by N. For capacity-adjusted planning, divide points by available person-days, then multiply by next sprint's available person-days.
How do I calculate average velocity in Jira?
Open your Scrum board, go to Reports, and open the Velocity Chart. If an average isn't shown, add up the Completed values for the listed sprints and divide by the number of sprints. Make sure the board's estimation statistic is set to Story Points.
Should you calculate individual velocity in Scrum?
No. Stories are delivered by the team, so per-person points ignore reviewing, pairing and unblocking, and they encourage people to game estimates. Use available days per person for capacity planning and leave performance assessment to other means.
Can you compare velocity between teams?
Not meaningfully. Each team's story points are relative to its own reference stories and Definition of Done, so 30 points on one team and 30 on another aren't the same amount of work. Use a multi-team velocity chart to show each team's own trend, never to rank them.