Why Not Velocity as an Agile Metric?
By Esther Derby
In response to my recent article on Agile Metrics, a reader asked, “Why did you leave out velocity?”
Even though it’s not perfect, velocity is the best way we have to understand the capacity of teams. It’s the best way we have to bring some reality to planning for releases. Watching velocity over time and looking at patterns in burn downs can alert coaches and managers that something is going on, and they need to investigate.
Velocity is important. But as a metric for gauging how your agile adoption is going, it opens a door to danger.
Here’s why.
- Velocity is easy to manipulate. Want velocity to go up? Fudge the definition of done and you finish more stories. Change the scale and complete more points (what once was a 2 point story is now a 5 point story).
-
Velocity is easy to misuse. Managers who don’t see organizations as systems can use it to compare teams or punish teams. Neither of which is helpful.
-
Velocity—as an agile adoption metric—puts the focus in the wrong place. Focus on velocity implies that if velocity isn’t improving there is something wrong with the team. In some cases, that might be true. But I don’t want people to look by default. When velocity isn’t improving or is erratic, it’s often due to factors that aren’t in the team’s direct control. There might be a problem with the way the work is flowing into the team. Or the team maybe interrupted every hour with production support calls (or what ever). Or the team may not have the tools they need to do their work. That’s something for the team and team coach to work on or raise up as an impediment (where mangers can work on it at the system level).
For assessing the progress of an agile adoption, I choose metrics that emphasize system performance to help managers make the shift from “work harder” thinking to “optimize the whole system” thinking. Managers after all, are responsible for creating the environment (structures, policies) and enabling conditions for teams be successful. To do that, they need a way to asses how the system is functioning. Because I presume that the point isn’t being “agile” but delivering valuable software.
Esther Derby works with companies who want to do better at delivering valuable software to their customers. She works with small niche firms, mid-size companies and Fortune 500 companies. She has worked in financial services, insurance, health care and manufacturing, as well as in product and software-as-a-service companies. You can read more from Esther on her blog. Check the AYE Conference.
Velocity should not be used as a “metric” at all. It is purely to assist the team (including the PO) to help plan sprints and releases.
A good agile team will want to try and increase its own velocity if it feels it is under-producing, but as you rightly imply it should never be told to increase its velocity because of perceived low productivity or being “off-track”.
Very interesting. A similar comment about the agility of velocity: Is velocity agile ?.
I am currently working under SCRUM methodology. But our Business Owner compares our teams using velocity as metric. I would like to know if someone could give me some book reference where explicitly clarify this.
Using Velocity as a metric is asking for trouble. As Ester points out – defining the scale used simply skewing the estimated number of points quickly makes this statistic meaningless. This is particularly true if there are numerous development teams which are loosely coupled. The thing I find amuseing is that is is so obvious to see thru the wool they try to pull over your eyes. The thing that rocks the most about Scrum is the visibility – no hiding in Scrum!
This is nicely illustrated by Esther.
I agree to all the points but I have also experienced
– convincing Senior Managers in the organisation who would want ‘at least some metrics’ to prove that its in control…
– I have also seen PMs acknowledging team members by the number of stories delivering every sprint/iteration!
And I think the problem is more about the cultural thing in the organisation so the change has to come from the Senior Management… Just teams doing SCRUM/TimeBoxing wouldnt help.
~Vishal