Velocity can be measured in various units - typically story points, ideal days, ideal hours, hours or some other more interesting unit of measure such as gummy bears. One of the key advantages of velocity is that it is fundamentally unit agnostic. It does not matter what unit you use to measure velocity, just as long as you remain consistent.
Of critical importance to achieving a reliable velocity is fixed-length iterations - typically from one week to one month. I often hear teams wanting to significantly vary the length of their iterations to accommodate other internal needs. There are already so many uncontrollable variables on a software project, why introduce another. By simply controlling iteration length, we are able to track a metric that conveys a completely accurate and unbiased measure of progress over time. From this historically accurate metric, you can then begin to reliably predict what your team can do in the future.
With velocity, we finally have a metric that, for me, has proven exponentially better at measuring project status than the elusive task hour per person per day. By maintaining the integrity of the metric (e.g., basing velocity on fixed-length iterations), we have a measure that we can actually count on. If we allow iterations to vary, velocity will never achieve the desired consistency and we are are back to guessing when we will be done.
For more information on velocity, see http://www.versionone.net/Resources/Velocity.asp and/or http://www.extremeprogramming.org/rules/velocity.html.
Comments