Velocity is Story Points per Sprint?
Velocity is Story Points per Sprint?

Velocity is Story Points per Sprint?

One colleague was complaining about the Velocity practice, one part is the definition of Velocity, he says:

  • In Scrum, we define velocity as the average of the story points finished by the team in the last “x” sprints.

Well, I have different opinions. When I first check their discussion, I want to jump out and say “you’re wrong on velocity!”, and I tend to refer to Mike Cohn’s definition to it. Well, after read the “User Story Applied” (2004) carefully, I found I would not prefer the way how Mike explains velocity:

  • Page 15 “Velocity is the amount of work the developers can complete in an iteration.”
  • Page 91, “We use the term velocity to refer to the number of story points a team completes (or expects to complete) in an iteration.”
  • Page 103, “As we learned in Chapter 8, “Estimating User Stories,” velocity represents the amount of work that gets done in an iteration.”

To me there is a sequence:

  1. first you choose a measure for your requirements (remember it doesn’t have to be user story), e.g. story points or ideal days
  2. compute the velocity based the measure you choosed
    • if you choose story points, velocity = accumulated story points / accumulated sprint count
    • if you choose ideal days, velocity = accumulated ideal days / accumulated sprint count

And I’d only use velocity to represent what happened, not “can”. Which means only compute it for pasted sprints, e.g. after a sprint review. And basically I don’t recommended using the term “velocity” while estimating how many things could be done, in the sprint planning, I would just call it “estimates”. To avoid confusion.

In my opinion, story points and velocity benefit the product owner the most, instead of the team. Coz the team could mainly rely on e.g. hours to plan and track progresses of their sprint. And it’s very easy for the team to keep a constant measure relation along the time. While for the product owner, in charge of several teams’ work, it’s very hard to keep a constant measure relation in the backlog, and story point or ideal days could help. Therefore I would make an explicit distinction that PO relies on relative size, team relies on definite estimates.

We must remember there are also teams who don’t estimate for user stories at all. As Ron Jeffries mentioned in scrumdevelopment yahoo group, they just split requirements into the same sized small user stories, and don’t estimate at all. So managing sprint is the easiest by just counting the number of stories, the velocity of their teams would be really easy too:

  • velocity = accumulated story count / accumulated sprint count

Who says velocity has to be with story points?

Some other links you might want to check out:


  1. Pingback:Scrum/Agile Starter Kit | BE AGILE & LEAN

  2. Pingback:Quote Ron Jeffries on Velocity | BE AGILE.KJ

  3. Pingback:Quote Ron Jeffries on Velocity | BE AGILE & LEAN

  4. tchen8

    Velocity is meaningful for the purpose of improve project’s predictability and visibility. IMHO velocity is actually serving for the upper management instead of the level of single sprints. To apply the velocity, the level of uncertainty is better to be stable, and the definition of done should be very clear. ‘Story points’ is preferred over the ‘Person-Hours’ however we can mix-use the both (story points for stories, person hours for tasks.)
    Splitting requirements into the same sized small user stories, and measure the throughput per sprint, is interesting however we need more evidence&success stories to support the applicability.