Velocity Is a Means, Not an End

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

Based on risk, complexity, and effort, story points purposely obfuscate our concept of what work estimates are. But, bear in mind, story points are not a direct replacement for time-based estimates. It’s like when an established sitcom has to recast a main character with a new actor. Be it the two Dicks of Bewitched, Roseanne’s Second Becky, or postnatal Aunt Viv on The Fresh Prince of Bel-air, sometimes shit happens and changes have to be made. Typically, these swaps are not addressed at all—Nothing to see here!—or result in a quick wink-at-the-audience joke. After all, the show must go on.

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?

Last century, when I was in college, I tended to write all of my papers the night before they were due. A few hours in the computer lab late at night and I could cobble together a few salient thoughts on the subject at hand without much strain. Then, all I had to do was change the font to Courier New, increase the line height, and bring in the margins ever so slightly to up the page count and meet one of the requirements of the assignment: length.

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?

A sprint’s success is measured in value, not velocity. Sprints should be planned with a delivered value at the end. Sprint goals tie back to this, setting the bar for sprint success not with a number, but with an achieved aspiration.

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.