https://groups.yahoo.com/neo/groups/extremeprogramming/conversations/topics/157102
Under what conditions (if at all) can Velocity be used as a productivity metric? and if if not, why not?
The "why not" is that velocity should be a tool used to get better at estimation and planning.
So some of the larger swings you see in a teams velocity - especially in a team new to agile - are due to them tweaking the various dials that help them get better at planning an estimating - for example:
- velocity increasing because the team gets better at splitting big stories into little stories
- velocity dropping because the team get better at including all of the things necessary into their definition of "done".
If you start looking at is as a "are we getting faster" metric - that'll get in the way of the utility of it as a way for the team to get better at estimation and planning (e.g. by over-splitting stories, or by ignoring some aspects of "done").
First, because the true value of Agile methods is obtained when value is obtained by scope management, not by trying to "go faster", so velocity metrics get in the way of learning to manage scope.
Second, because since the points are estimated by the developers, if you ask for more points, they'll just estimate things as being more points. Not because they're evil, but because they're human.
Third, because if you are asking more more velocity, the team feels pressure. Under pressure, the team will get more "done", because you're asking for it, but they will do so by skimping on things that matter, like testing and collaboration and code quality.
...
However, "productivity" is a measure of work, not of value. Why not measure the value of the work done instead, and recognize that the value lies as much, or more, in what you do, not how fast you do it?