Or why I believe Velocity shouldn’t be a communicated metric and definitely should never be a means of comparison.
Tl;dr – A note to PM’s – communicating Velocity as the sole indicator of project progress will bite you. Do not fall into the trap of lazily comparing team velocities; it can cause the emergence of a number of detrimental anti-patterns and your teams won’t thank you for it.
Let me start by saying Velocity IS a valuable metric in all sorts of ways; it helps Agile teams work out capacity for the next sprint, helps Product Owners make sure they have enough detailed work items prioritised and ready to go. Watching a team’s velocity over time can also indicate issues (if you have a consistent definition of done) and allow Project Managers or any team member to suggest improvements and helps bring some reality to the estimation process.
There is a common thread in all these things; Velocity is a valuable metric WITHIN the Project team. As soon as it becomes a communicated metric you’re probably going to hit some problems, especially if you don’t make it clear Velocity is not a literal base-lined value. It varies between teams naturally and is relative.
If all your teams are reporting velocity, I guarantee someone somewhere in your business will compare them and make snap judgements. Even if they don’t voice it, they’re thinking it; and if they do voice it, it tends to drive a number of anti-patterns.
This is especially true if Velocity is the only metric or guidance you give the wider business on Project progress.
Firstly if a team’s velocity is questioned against a perceived ‘higher velocity team’ then the team in question will, more often than not, seek to normalise their story-pointing and therefore their velocity. They may simply inflate their values to make sure they match or beat the higher value. This can be a subconscious process.
Secondly, teams will start to focus on Velocity. This could lead to fudging of the definition of done; an unwillingness to investigate and discover further work items or to accept any change that hurts Velocity.
Most insidious of all, teams could start demanding very rigid specifications before implementing work items. This can lead teams to implement to plan in a robotic fashion, rather than initiating discussions with the Product Owner/Stakeholders on better ways to achieve the desired result.
None of the above outcomes are desirable.
However tempting it is, as Project Managers/Team Leaders/ Agile coaches we have a duty to shield teams from this behaviour and not perpetuate it. If you absolutely must report Velocity make sure it is not the only indicator of progress you provide to the business.
As a PM, you should reinforce the message (to the wider business) that the only true way to judge progress is to be involved. Attend show and tells, take interest in the content of releases and most of all ask questions and give feedback.
Some will argue that all the above can be mitigated; and of course they can, but in my experience Velocity ranks up there with estimation for most misunderstood factor.
I admit Velocity is an extremely convenient figure to use; but you should view it as a tool rather than the absolute proof of progress. As a PM, in conjunction with the Product Owner, you need to drive engagement in your project, not use Velocity as a shield.