Velocity, the False Metric of Productivity

There has been so much written about Velocity and its impact on teams, yet it is one metric that eludes everyone and keeps cropping up whenever there is discussion around productivity.

Is it really a metric of productivity? Let's explore.

What Is Productivity?

Productivity is defined as the state or quality of being productive, and the effectiveness of productive effort, especially in industry, as measured in terms of the rate of output per unit of input.

A couple of questions arise here:

• Are we machines to which an input can be fed and a fixed output can be achieved?
• Do we, as software professionals, do work which gives us a fixed output given a set of input activities?
• Can this output be increased if we put in more hours?
• Given that we spend 8 hours in front of a system, will we always be able to write the same number of lines of code (or increase that over a period of time, if that is productivity) that will always deliver value?
• Is value delivery directly proportional to the number of lines of code that we write?

If you have answered any of the questions mentioned above as "Yes," please connect with me and enlighten me with your perspective. I am open to learning.

If your answers are a "No," then we in on the same boat and we can explore this topic further, together.

What is Velocity?

In kinematics, Velocity is a physical vector quantity to define which we need both magnitude and direction.

With reference to Scrum Teams, it is the amount of Product Backlog Items converted to potentially releasable "Done" Increments at the end of every sprint, often measured using Story Points as the unit.

This leads me to another set of questions:

• Are the teams focused on value delivery or delivering more story points?
• Do these story points even capture the notion of direction or just speed?
• If it is just speed and no direction should we even call it "velocity"?
• How delivering more story points determines that teams are delivering value?
• How do we know that the Story Points are not inflated?
• When Story Points themselves are arbitrary numbers does it even make sense to measure them and consider for those as a measure of productivity?

What Velocity Is Good or Bad?

In my experience so far, velocity is neither good nor bad as long as it remains internal to the team and is never utilized for any purpose/reason outside of the team. The unit to measure it and the decision to measure it or not should be left to the Scrum team, which is self-organizing and capable of making its decisions.

So Where Does Velocity Help?

Velocity helps in only one aspect and that is to make certain forecasts by the Product Owner that would help the business to take some decisions related to scope versus time. For example, knowing the worst, average, and best velocity of the team and having an ordered and estimated Product Backlog, the Product Owner may inform the stakeholders how long will it take to deliver a piece of functionality from the Product Backlog or predict when a set of functionality would be ready. With this information, businesses can make strategic decisions like participating in a road show, releasing a product update, announcing dates for upcoming releases, and so on.

However, a word of caution: in a complex environment nothing replaces empiricism. When there are more unknowns than knowns, we do not know what would happen. Inspection and Adaptation with Transparency at the last possible moment trumps all the metrics.

Conclusion

Velocity is an output not a desire. It is only helpful to an extent and that is to help the business make some forecasts. There is no good or bad velocity. If it is being used to measure anything else besides forecasting then we are using a wrong metric for a wrong purpose.