Projecting Velocity is Useless
How do you measure velocity?
Based on number of functionally tested features deployed OR based on number of estimated story points (or whatever your estimation unit is) that were completed in a time box?
If you are using story points (Nebulous Units of Times {NUTS}), then I don’t think projecting your velocity and drawing conclusions based on the projection makes any sense. Because:
- you are tracking against what you thought at point X in time. And lots of things have changed since then.
- this method makes a fundamental assumption that the % error in all your estimates is approximately same. If we are 10% behind schedule, we’ll stay 10% behind schedule as far as we develop things at this rate. Personally I don’t think this holds good. Because your estimation errors vary across your estimates.
In my experience velocity is not a straight line, its filled with curves. As the project progresses, you don’t necessarily have a linear velocity. Estimates make you believe that its linear. In fact what I’ve seen is that the velocity seems to slow down and pick up. One needs to regularly invest in paying off the technical debt and then they see the velocity go up again. There are also other reasons why your velocity will vary and won’t follow a straight line. So projecting a line based on your velocity might be misleading.
By looking at the progress without making any explicit projection, a team can get an impression of how the project is doing. Usually I try to do a breadth-first approach of all the important features. What this means is that I don’t have a feature fully 100% ready while others are 0% complete. I work on the very basic needs of all the top most priority features and later add more sophistication as needed. This gives me a big advantage. Now I don’t just vary scope by adding or removing entire feature, but I can also vary scope by increasing or reducing the sophistication levels of different feature.
This approach in my experience reduces a lot of delivery and expectations related risk. If this approach is followed, in the worst case, on the day of delivery, I’ll have, if not all, most features available with varying sophistication instead of varying internal quality. Best case I have the right set of features (without any extra/useless features) fully functional ahead of the promised time.
