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:
- first you choose a measure for your requirements (remember it doesn’t have to be user story), e.g. story points or ideal days
- 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:
- wikipedia entry (not Scrum specific): http://en.wikipedia.org/wiki/Velocity_%28software_development%29
- scrumalliance article: http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms#1110
- colleague’s blog post: https://scrumplicity.wordpress.com/2011/11/11/226/
- Mike Cohn’s presentation: http://www.mountaingoatsoftware.com/presentations/advanced-topics-in-agile-planning