Published on December 28, 2023
8 min read
Languages are dynamic. They grow and change shape. Existing words are repurposed to describe new ideas. Sometimes it’s helpful. Often it’s harmless. But in some cases, like today’s example, it results in layers of absolute and utter nonsense that compound gloriously.
The scientific definition of velocity is precise and useful:
v = the change of distance in a given direction ÷ the change in time
Thus, a car that moves 60 miles east between 3:00 and 4:00 pm has a velocity of 60 mph east.
Alternatively, in casual conversation, many use velocity and speed interchangeably when referring to any rate of change. This too makes sense as a formula:
v = measurement of change ÷ the change in time
If you’re following Scrum, or another software development methodology with fixed length work cycles (i.e. Sprints), the commonly accepted formula for velocity is:
v = story points completed ÷ work cycle
Therefore, a team that completes 80 story points in a sprint could be said to have a velocity of 80 story points/sprint, or commonly simplified to 80 points.
Does this formula make sense? To answer that, we first need to define our unit of measurement. What exactly is a story point?
Ron Jeffries, likely the inventor of the story point, explains they were first used to estimate time. However, a recent informal poll on LinkedIn shows story points are also used to factor effort, complexity, risk, and uncertainty into work estimates.
Does that change anything? No.
If you use story points to figure out how much work can fit in a fixed time period—story points are always an estimation of time. Call it what you want, but know that time is the subject matter.
In the article linked above, Ron Jeffries explains the switch from Days to Points was intended to abstract estimations away from time. Why? Although Days accurately communicated that these were time estimates, the difference between the team’s definition of an Ideal Day and a calendar day was lost in translation.
With what result? This misunderstanding exaggerated disparities between estimated time and actual time, prompting stakeholders to focus on that. It’s not hard to imagine that Mr. Jeffries and team found this to be an unhelpful distraction that did not contribute to the performance of an engineering team. And thus, points. [Thank you to Ron Jeffries for taking the time to review the above 2 paragraphs for accuracy.]
As time has passed, this verbal sleight of hand has grown increasingly complex. One team may adopt the Fibonacci sequence. Another, in an attempt to emphasize the inexactness of the estimates, may use round numbers to lower the implied precision of that sequence (e.g. 20 vs 21). Still others will avoid numbers altogether and use T-shirt sizes, although they are often later translated back to… you guessed it!… numbers. The purpose of all this? To pretend we’re not talking about time.
Lest we fall prey to our own tricks of misdirection, if points are being used to fit work into a defined time period, all of these schemes reduce down to a measurement of time. Yes, this point was made earlier, but it bears repeating.
Much effort has gone into clouding the direct relationship between points and time. As a result, story points have no standard unit of measurement. We know this. It is the reason comparing points between teams is generally recognized as bad practice. Apples, meet oranges.
So back to our question, does this formula for velocity make any sense?
v = story points completed ÷ work cycle
With no standard unit of measurement for story points, velocity—in the general case—must be understood as:
v = <undefined term> ÷ work cycle
That, dear reader, is utter nonsense. But wait, there’s more! After all, you were promised this nonsense would come in gloriously compounding layers.
Can you guess what happens when management hears about velocity?
“You have a way to measure engineering speed? Great, we need to go faster!”
Meet your new KPI: Continuously Improving Velocity.
To be abundantly clear, this is not good. We established that velocity, as a general measurement, is meaningless. Now, our success is being measured by… doing more of it. 🙄
However, I’m in a glass-half-full kind of mood. So, is this KPI salvageable?
Putting the general case aside, let’s argue that within a single team a story point will be used consistently enough to make it a useful quantifier. In that setting, does increasing velocity make sense as a measurement of engineering performance?
Our fictional team has chosen to use each story point to represent the work that could reasonably be completed in one working day. Effort, complexity, and risk are factored into their estimates.
In each of the following three scenarios, the team selects 80 points of work for the cycle. They do not work any overtime.
This seems improbable, but let’s roll with it. The team completes the exact 80 points of work scheduled.
Now tell me, how does this team increase velocity? Given that story points are an estimation of time, not output, there is only one way for a team with perfect estimates to increase velocity:
A more likely scenario, the team’s estimates are imperfect. They overestimated how long tasks would take. As a result they were able to complete 90 points.
It’s critical to note that capacity did not increase to 90. Points ultimately represent time. The team did not figure out a way to make more time. So what happened? They guessed wrong.
What’s morbidly interesting is that if their prior cycle’s estimate was more accurate, then this estimation error will appear as “increased velocity”. Good job, team! 👍
But that’s a single cycle. How can the overestimating team continue to increase velocity? They have an additional option over Scenario 1:
Perhaps the most realistic scenario, the team underestimates the time required. The work cycle ends and the team completed 70 points.
Unfortunately, if prior cycles’ estimation accuracy was higher, this wrong guess will show up on KPI reports as a velocity decrease. 📉
With rumors of layoffs swirling, how does the underestimating team increase their velocity? They have the most options. Too bad they’re all terrible:
Yes, of course, the pun is intended.
One last detail that is exceptionally important to internalize is that in all three scenarios exactly the same amount of work and value was delivered. The only thing that changed was the accuracy of the estimates.
This is an example where the choice of wording, specifically velocity, has done a great disservice. I’m not blaming anyone. I mean to imply no malintent. Regardless, the outcome is the same.
So let’s drop the jargon and call things as they are. The formula for what we’ve been talking about is:
estimated time ÷ actual time
Looking at that formula, what does it describe? Accuracy of estimation. Does the label matter? Yes! If we called it what it is, estimation accuracy, imagine what would immediately become plain:
That’s a shame. Because if you’re using story points to do so, it’s not what your numbers mean.
This last piece is painfully amusing. You’ll recall from earlier in the article, story points were introduced to do what? To counteract a tendency to focus on variations between work estimates and actual time spent.
And what have we done?
Under the name of Velocity, we’ve memorialized and spotlighted this very thing as a core metric. But we couldn’t stop there, could we? Oh no. Through mislabeling and misdirection we also managed to make it far more confusing along the way.
Bravo! Bravo. 👏