JIRA Agile features are now available in the standalone application JIRA Software. Please upgrade to the latest version of JIRA Software to get all the latest and greatest features. Visit the Migration Hub for more information, or see the Administering JIRA Applications documentation.


The velocity of a team is a measure of how much work that the team can handle within a specific time period, i.e. how much of the product backlog can be completed by the team in a sprint. Velocity can be calculated on the basis of story points, business value, hours, issue count, or any numeric field of your choice (see Configuring Estimation and Tracking).

Screenshot: Velocity Chart (click to enlarge)

/download/attachments/391087316/gh_6-2-1_velocity-chart.png?version=1&modificationDate=1367983125306&api=v2" width="550" height="307"/>

The velocity can be estimated as the average, over several recent sprints, of the sum of the estimates for the amount of work completed by a team per sprint — so in the chart above, the velocity = (37 + 47 + 50 +57) / 4 = 48. A team's recent velocity can be useful in helping to predict how much work can be completed by the team in a future sprint.

See Viewing the Velocity Chart.

Was this helpful?

Thanks for your feedback!

Why was this unhelpful?

2 Archived comments

  1. User avatar

    Egor Kachanov

    I have some problems with calculating average velocity. Case:

    In Sprint 1 we take story with 21 s.p.. At the end of sprint we didn't finish story, so "Completed"=0. At sprint 2 we re-estimate story to 13 s.p (part of work we done, so estimate decrease). Again we didn't finish story and "Completed"=0. At sprint 3 we re-estimate story to 3 and finish it in sprint, so Completed=3.

    So velocity in JIRA = 1 s.p. per sprint (3 s.p/3 sprints), but in fact real velocity must be 7 s.p. per sprint. With wich tools we can calculate real velocity?


    17 Jan 2015
  2. User avatar

    Brandon Schmidt

    A couple recommendations:

    1. Any story that you're not going to complete within the span of a single sprint should probably be considered an epic and then broken down into smaller stories that each still offer some level of value. Smaller stories = better chance of delivering value at the end of the sprint and 'earning' story points to factor into your velocity calculations.
    2. At the very least, don't change the estimate on the story. When the story finally gets closed, you want the team to get credit for the full amount of work completed (in this case 21 points). If you're re-estimating so that you get a sense of how much effort is still remaining, make a practice of using sub-tasks and modifying the remaining time left on those.


    05 Jun 2015
Powered by Confluence and Scroll Viewport