Velocity In Scrum is a Means, Not an End

by John Ragozzine

Being a scrum master, I often worry if velocity looms too large for me. From project forecasting to sprint planning to team retrospectives, velocity metrics are up in my grill more than bratwurst at a Green Bay Packers tailgate. Even from a “book learnin’” standpoint, velocity is front and center: “ The Scrum Master is accountable for the Velocity … of the Team. “ That big V Velocity is really intimidating! But does velocity warrant such verbal (and mental) emphasis?

Now, I am not saying that velocity isn’t an important metric. Velocity factors hugely into both planning attainable sprints and reliable deliverable dates. And frankly, high performing teams’ velocity goes up because they work more efficiently and effectively over time. I have noticed a tendency to treat velocity as the be-all and end-all for measuring team success though, which can result in unnecessary anxiety and lowered team happiness, both of which lead to unstable teams, and ultimately, a reduction in overall velocity.

So why do some scrum teams fixate on velocity as the premier success indicator? I think it stems from that awkward moment in agile adoption when teams replace time-based estimates with the building blocks of velocity: story points.

It’s time for story points

The danger here is applying time-based (quantitative) measurement thinking to teams working in story points. So often, the work ethic of a person is expressed in time. Saying that someone “works 80-hr weeks” is supposed to connote a hard worker, but how valuable are those hours? It’s almost never said that someone is a hard worker because they delivered some qualitative value to their customers.

“But John,” I imagine you saying, “what about work that is measured in units made/sold/shipped/etc?” I counter with an anecdote of ill repute.

Quality or quantity?

It goes without saying that the aim of my professors was to get more thoughts out of me to fill more pages, not for me to experiment with MS Word’s formatting options. I met their quantitative requirements, but likely failed on the qualitative opportunities.

Focusing on story points delivered in a given sprint carries the same success semblance that, when scrutinized, shows how little is really there. Can you imagine if we paid web developers by the character counts of their code? It sounds silly, but this “more is better” mindset can lead to “highly productive sprints” with high delivered story point counts that ship diddly squat to the market.

So how do we measure success in scrum?

Velocity is a valuable metric in scrum, but it is only part of the wider story. Be aware of it, work to increase it, but be wary if your story points start wagging the dog.

This post originally appeared on John’s personal site on April 20, 2020.

We are strategists, researchers, designers, and developers who craft digital experiences for publishers, nonprofit institutions, museums, and brands.