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?
As defined (n): the state or quality of being productive
- 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:
- Are we machines to which an input can be fed and a fixed output can be achieved?
- Are we, as software professionals do work which gives us 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 system; will we always be able to write same number of lines of code (or increase that over a period of time; if that is productivity) that would always deliver value?
- Is value delivery directly proportional to the number of lines of code that we write?
- the effectiveness of productive effort, especially in industry, as measured in terms of the rate of output per unit of input.
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 learn.
If, to questions above, your answers are a "No" then probably we are 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 i.e. how fast and which direction.
With reference to Scrum Teams, it is the amount of Product Backlog Items converted to potentially releasable "Done" Increment 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 term 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 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 vs. time. For ex: 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 by when a set of functionality would be ready. Having this information business 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 nothing beyond that. 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.