Team Velocity as a measure of Working Software
Updated: Jan 15
In this short article, I’d like to give some hints and insight to Scrum Teams using velocity as a metric.
Both Agile manifesto and Scrum emphasise “Working software/increment” as the primary measure of progress. “DONE Increment” is at the hearth of Scrum and is one of the three artifacts. To be able to use true empiricism, you need to have transparency over what you have “DONE” hence you can inspect/adapt , i.e plan what you want to do and what you can not afford to do.
So how does velocity can serve to this purpose ? If your velocity — which ever unit you are using (T-shirt, story point etc) — shows how much product you are completing, that might help you to project the future — given the future is not certain yet and can change.
Why am I stating the obvious? I am seeing lots of teams using velocity to show their effort spent during the Sprint not the amount of product they deliver. Some even try to size the refinement activities and add it to their velocity. In such use, velocity loses its transparency and becomes a different metric which is fine if your intention is to measure your effort and your planning capacity. However, I like velocity showing the amount of working/releasable product delivered in a Sprint.
Is there a reason why teams have such preference ? Most of the time yes. It is because velocity is used by management in a way to measure the performance of the teams. Management wants to see high utilisation, high numbers, high planning accuracy. Therefore velocity is gamed to fulfil what is expected of the teams. So here my advise to management is not to use velocity to measure performance. When done, it becomes an non-transparent metric with diminished value.
Velocity in physics is the amount of distance taken within a time. It can be used how much time you need to reach a destination — given you retain your existing speed and you don’t have to de-tour due to changing circumstances — things like accidents, road blocks. However a smart navigator would tell you when you are going to arrive your destination by taking into account your most up-to-date information (velocity, road circumstances, the new route you have taken). So can we not employ the same mechanics in Scrum teams ? Be able to use your velocity to do smart estimates. Keep your correlation between your velocity and releasable working software high.
Hope this make sense to you.