Why Not Velocity as an Agile Metric?

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.