Unfortunately the link is a little longer than I have time to view today, but I will put it on my to-watch list ;-)
As you say, velocity is a poor metric. But before I explain what I mean by that, I should define "metric". The dictionary defines it to be simply a measurement, but in software process engineering, "metric" is often a special term. It means a measurement that you use to modify your process.
The problem with velocity is that it is a measurement that is highly dependent upon your process. It simply divides an amount of work by an amount of time. However, the amount of work is actually a random variable with a certain distribution. When you change your process, the amount of work changes (as does it's distribution). So the end result is that if you have 2 processes, P1 and P2, with velocities, V1 and V2, V1 is almost completely unrelated to V2. This means that you can't use it to measure the success of process changes.
However, velocity is not useless. It is an excellent measure (not metric). Before, I mentioned that you are dividing an amount of work (a random variable with a certain distribution) by an amount of time. You may not know what the distribution is for the amount of work done, but if you take the mean of a sufficient number of these random variables, then that mean is roughly normally distributed (as per the central limit theorem).
In plain terms, this means that if you have enough small stories, the average amount of work for each story will be roughly normally distributed. As long as you don't change your process/programmers/etc the amount of time it takes will also be roughly normally distributed. So by taking some measurements, you can estimate (with error bars!) how long a given set of stories will take -- as long as nothing changes.
That last bit is important and is why velocity makes a poor metric. In fact, it is such a poor metric that IMHO you should never publish your velocity. Work in story points and leave calculating the overall estimated time of completion to someone who is not doing the work. Otherwise someone will start asking questions like, "How can we get our velocity higher?" (it has happened on every team I've worked on).
Incidentally, I have experimented with modelling requirements discovery during development -- i.e., trying to predict how much extra work will be added to a project from any given point until you ship. It seems to follow a curve that is very similar to Littlewood's defect discovery model (which is probably not so surprising). Again, by estimating the average rate at which requirements are added, one can probably estimate how much extra work will be required in addition to that already planned.
I hear you, I've also heard "How can we get our velocity higher?" more times than I can count.
What I don't like about velocity is that it encourages the gamification of the process. Developers start caring more about their velocity than the quality of their code and before long nobody has any clue of the big picture and the project starts going down the drain.
Working in the video game industry, I see the striking difference between playing games and developing games first hand, every day :)
As you say, velocity is a poor metric. But before I explain what I mean by that, I should define "metric". The dictionary defines it to be simply a measurement, but in software process engineering, "metric" is often a special term. It means a measurement that you use to modify your process.
The problem with velocity is that it is a measurement that is highly dependent upon your process. It simply divides an amount of work by an amount of time. However, the amount of work is actually a random variable with a certain distribution. When you change your process, the amount of work changes (as does it's distribution). So the end result is that if you have 2 processes, P1 and P2, with velocities, V1 and V2, V1 is almost completely unrelated to V2. This means that you can't use it to measure the success of process changes.
However, velocity is not useless. It is an excellent measure (not metric). Before, I mentioned that you are dividing an amount of work (a random variable with a certain distribution) by an amount of time. You may not know what the distribution is for the amount of work done, but if you take the mean of a sufficient number of these random variables, then that mean is roughly normally distributed (as per the central limit theorem).
In plain terms, this means that if you have enough small stories, the average amount of work for each story will be roughly normally distributed. As long as you don't change your process/programmers/etc the amount of time it takes will also be roughly normally distributed. So by taking some measurements, you can estimate (with error bars!) how long a given set of stories will take -- as long as nothing changes.
That last bit is important and is why velocity makes a poor metric. In fact, it is such a poor metric that IMHO you should never publish your velocity. Work in story points and leave calculating the overall estimated time of completion to someone who is not doing the work. Otherwise someone will start asking questions like, "How can we get our velocity higher?" (it has happened on every team I've worked on).
Incidentally, I have experimented with modelling requirements discovery during development -- i.e., trying to predict how much extra work will be added to a project from any given point until you ship. It seems to follow a curve that is very similar to Littlewood's defect discovery model (which is probably not so surprising). Again, by estimating the average rate at which requirements are added, one can probably estimate how much extra work will be required in addition to that already planned.