I like tracking velocity for an iteration when I'm using agile. Teams often take several iterations to find their velocity--anywhere from 3 to 7 iterations. That's because the team has to relearn how to estimate, to make requirements user stories, to think about what done means, and how to make their stories smaller. I like estimating in points rather than hours or days, and that can be a challenge for people who are unaccustomed to thinking about relative size rather than duration. (See How to Estimate Without Time Units for a quick summary.)
I find tracking velocity helpful in these ways:
- Once we get past the first few iterations, velocity should be relatively constant, unless people are missing. If it is not, that's an indication that something might not be right.
- A decrease in velocity, assuming no one is on vacation or away, may indicate technical debt.
- An increase in velocity may indicate technical debt because the features are not really done.
- Or, a velocity increase may be a result of the team revising how they create user stories or estimate.
Velocity changes are not good or bad, they are. And, if you track velocity, you will have more information about the team's progress.
I particularly like to track velocity as a burnup chart.
You can see in this image that requirements increase over time (what a surprise :-), and that the team has a relatively constant velocity. This team had been together for a while which is why their velocity was relatively constant. When the product owner decided to increase the number of requirements, they were able to predict (and meet) their new date for release.
Velocity work as long as you are using some form of incremental lifecycle. Since agile is iterative (using timeboxes) and incremental (completing features as you proceed), velocity works well to indicate real progress.
