In previous post “Velocity is Story Points per Sprint?”I mentioned that velocity could be the accumulated story count / accumulated sprint, and I saw it from Ron’s reply in one scrumdevelopment group discussion.
Unfortunately I didn’t save that post, and I couldn’t search and find it now, however I found a discussion from last year in the group, I quoted some of Ron’s comments here, it reflects the same idea.
- http://tech.groups.yahoo.com/group/scrumdevelopment/message/49853 (Ron explains velocity as one of its inventors)
And some brief quotes below:
- The primary value of velocity is to know [roughly] when we will get somewhere. Using past velocity to estimate how much work to take on next week is OK, but it isn’t the point. The point is to use progress to date to predict future progress.
- I don’t recommend velocity.
- Just count what’s done. Time spent fixing bugs is waste, and it will be shown by the amount of work done being reduced.
- Velocity is /defined/ as the number of stories the team completes per unit time. The notion is specifically designed not to be “the amount of work” the team completes, because the focus should be on what the customer (product owner) wants.
Velocity is stories done per unit time. And that’s all there is.
So, actually count velocity as number of stories the team finished per unit time is not an alternative, it’s actually how it is used in the beginning when XP guys invented it. Does it surprise you?