Why not velocity as an agile metric?

This content is syndicated from Insights You Can Use by Esther Derby. To view the original post in full, click here.

In response to my recent post 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’s 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.

For more about using velocity as a measure, see my post Working Hard or Hardly Working.


© derby for Insights You Can Use, 2011. | Permalink | 20 comments | Add to del.icio.us
Post tags: , , ,

Feed enhanced by Better Feed from Ozh

Leave a Reply

What is 4 + 2 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”

DAN PULHAM, DIGITAL DIRECTOR
TELSTRA