A recent discussion on the ScrumDevelopment Yahoo! group discussed the different uses and misuses for velocity. Kurt Häusler described his understanding of velocity and its value:
Hi, velocity is measured by counting the number of story points done in the last iteration. I am not sure if it is suitable as a productivity metric. For me it is a neutral measure to be used as a tool to work out how many points to attempt next iteration. A lower or higher velocity for me is not necessarily better or worse.
However velocity is an important tool, if you understand what it is and what it is for, which as far as I know is planning the next iteration rather than measuring productivity.
Kurt also acknowledged that this is not the only view on velocity by Joe Little's blog where Joe states:
...we will double the team's velocity. In 6 months or less.
Doubling velocity (story points done-done in each sprint) usually means we must improve several things:
- a clearer definition of done (or "done, done" if you prefer). Usually we let this be too vague. Vary it must for some stories, but for most SW dev stories it must be very clear and can be consistent. And in my opinion, it must mean "no [known] bugs escape the Sprint". And testing must include at least functional testing.
- we must measure velocity. I still can't believe how many teams I find that don't have some measure of velocity. More on this next time. For now: "Velocity: don't leave home without it."
- we must prioritize the impediments, and keep removing or reducing the top one until velocity is doubled. Hint: We might want to prioritize the impediments by how much the removal/reduction will increase velocity. 25% here, 30% there; pretty soon you're talking a real increase in velocity.
Hint: Improving quality and reducing technical debt are almost always important keys to seriously increased velocity. Not the only keys, but very important.
Adam Sokra agreed with Kurt that velocity is a poor performance metric, but sees velocity's main utility in long term planning instead of iteration planning:
It is an exceptionally poor performance metric, unless your intent is only to see how your productivity stabilizes over time. Velocity has been used to say, "last iteration we completed X points, so this iteration we should attempt no more than X." However, many of us have come to believe that this is a dubious way to make commitments. It has been suggested that we simply commit to what we think we can accomplish each iteration.
Velocity is best used for long term planning. I can look at my velocity over several iterations and come up with an average (Preferably a range.) Then I can use that information to say things like: 1) Given the current backlog, how many iterations is it likely to take to complete a given set of stories? 2) How many story points, and by extension what set of prioritized stories, can I deliver by date X (e.g. in time for the trade show?)
And, of course, there is a growing school of thought that views planning as a wasteful activity.
Should velocity be used a metric for productivity? Should it be used for iteration planning? What about longer term release planning? Should it be used at all, or is it a wasteful practice?