Velocity pitfalls to be aware of

Measuring and using velocity of an agile team can be helpful in forecasting output of the near future. You need a certain stability in your team and enough data points / iterations. However, there are also things that could go wrong using velocity. Therefore I want to shed some light on pitfalls using velocity in agile planning.

Velocity is not a measure for productivity!

Velocity is only an indicator of how much work was done in the past, not how much work will be done in the future. It’s like measuring your running speed with a stopwatch and then using this value to predict how fast you can run tomorrow or next week. We would be able to predict who will be next olympic gold medalist based on past performance. But we would be wrong.

Don’t plan too far ahead and don’t plan too detailed!

Planning is a good thing, but don’t overdo it. If you do so then your plans will become obsolete very soon because things change fast in agile teams (from my experience also in non-agile teams). So don’t plan more than 2-3 iterations / sprints into the future.

Velocity measures output!

If output is what you want, then velocity can guide you in terms of forecasting (not predicting!). Very likely though, if you work with agile teams, is that you’re more interested in outcomes (what comes out after people are using your service or product) instead of the number of items of functionality shipped.

What about quality?

As mentioned velocity is a lagging indicator, it’s not a measure for quality. So on the hunt for stable or even increased velocity, don’t forget to plan your testing activities and test automation as well!

The human factor!

Velocity is a measure for output, not productivity or performance of your team members. So don’t use velocity as an indicator to motivate people and reward them with bonuses (or penalties). If you do so then there’s a high risk that this will backfire on you in terms of motivation because velocity is not a measure for performance.

–

Velocity can be used as an indicator to forecast output of your team, but it’s only one input in this process and you need more than just velocity to make good forecasts / plans. IF you want to dive deeper into agile planning I can suggest Agile Estimating and Planning. Be reminded that in the end it is not about plans or forecast but solving problems and adding value.