Lost in Velocity.

Shouldn’t we estimate spikes and bugs? What about “ghost work” like time spent on professional growth? Maybe we should re-estimate tasks that we partially completed? What if we associate story points with hours worked? That would make it easier for us to know how many story points to remove when Bob goes on holiday, and therefore more accurately plan. Or maybe let’s just add the number of points we think Bob usually completes in order to maintain our velocity.

These are all questions I hear quite frequently. And the discussions around them in my opinion are focusing time and energy on the wrong thing.

The forest for the trees.

Velocity is a tool. It is supposed to help us plan capacity by reflecting summed story points (estimated effort) of completed tasks. However due to the nature of complexity, in most cases not all tickets can be estimated meaning velocity also only represents the effort of the tickets that the team chose to estimate.

This inevitably leads teams (and management) to think that velocity therefore is not an ‘accurate’ representation of effort. Which is true. A metric that is essentially made up of estimates never can be accurate, more over one that doesn’t capture ‘the full picture’. However, because the general line of thought seems to be that, when estimating our capacity, our ‘predicted’ velocity is something that we must commit to, suddenly so much time and energy go in to trying to ‘make’ estimates and velocity as a whole more accurate. Teams fall into the trap of Goodhart’s Law by treating velocity as some kind of goal and begin to try to optimize for it, regardless of the consequences.

The typical consequence is that attention is diverted away from something more critical — delivering value. And because velocity is at the mercy of complexity and an abstract measurement system (story points) that many people already have a hard time grasping, discussions on this topic are generally not swift, sometimes going full-circle or resulting in questionable actions — like manipulating points.

While velocity is supposed to help us understand how much we can achieve — “how much” means absolutely nothing if we are unable to deliver value.

Committing to volatility is not a good idea.

While it is easy to get lost in discussions around velocity and how to improve your capacity planning or estimates, because you feel pressure to treat it as a commitment, there are a few reasons why you should resist the temptation.

When you are estimating a product backlog item, it is usually at a time when you know the least about it. This is reflected in the cone of uncertainty, where you can be off by a factor of four in either direction. This can be applied at a product level also. We simply cannot provide an ‘accurate’ estimate/ timeline for a single item of work let alone a new idea or initiative before we’ve even begun work. A bit like how in age of empires the map is covered by fog of war until you send out your villagers (incidentally the cheapest unit) to either find resources, or be killed by rabid wolves, wild boar, elephants or the enemy. Only by reducing batch size, iterating and accepting a certain amount of risk, can we reduce the overall uncertainty and risk.

Planning and estimating are also activities that are affected by the Law of Diminishing Returns. Because of the amount of uncertainty and luck that exist in software development, your best efforts may be neutralized by conditions you have no control over. That is, the amount of tracking and planning and trying to improve is not proportional to an increase in returned value. Regardless of whatever it is you think you will accomplish, and no matter how accurate or certain you think you are, someone will get sick unexpectedly, priorities will change, or maybe, just maybe, something might actually happen in your favour.

If you ever take a look at an average teams’ velocity chart it will usually be a mixture of peaks and troughs. This is not necessarily because their estimates or planning was terrible but simply because performance is determined not just by skill, but also by degrees of chance. The ratio between the two causes outcomes to naturally vary around some average (as most velocity charts do).

What’s more is that the statistical phenomenon known as Regression Towards the Mean explains a tendency for extreme outcomes to be followed by more moderate ones when there is luck involved. For example, if you planned or performed particularly badly during one sprint and so tried to estimate better and/ or come up with some improvement actions, your performance will tend to be better in the next regardless of what you do to improve the situation. This isn’t to say that your efforts are completely in vain, there is just no way of proving that they alone made a difference. Anyone however who says otherwise is over-simplifying something complex into a cause-and-effect narrative (narrative fallacy). At the end of the day, if we knew consistently what we could accomplish or how well we would perform and the steps to do it, then everyone would be winners at the races 🏇.

Nevertheless, there will come a time when fussing over velocity no longer pays off. It becomes a matter of knowing when to stop.

Velocity therefore is an inherently volatile metric, and is not a number you should commit to nor invest too much time trying to control.

Velocity isn’t completely useless.

All of this so far might be making velocity (and perhaps even estimating) sound a little pointless. However, you don’t necessarily need to jump on the #noestimates bandwagon just yet. While the randomness involved means that we shouldn’t worry too much about individual sprint velocities, the average or trend that emerges over a period of time can be useful to us.

Of course, velocity is the product of story pointing, so for this average to have any value, you need to estimate and assign story points preferably to most of what you will work on. By all means try to hone your estimation skills and learn from mistakes, but don’t overthink this. You do not need to estimate everything all of the time. Even if you have a sprint that’s packed with spikes or bugs, this is most likely an exception, not the rule. (If it isn’t, this is a different problem to be solved…).

Probably at some point, because of the above-mentioned uncertainty and chance, you will over-estimate your tasks, inflating your velocity and ‘balancing out’ previously lower velocities. Again, it’s not about the individual velocities, it’s about the general track record. Even then, rather than focusing on the average as a singular number (which can be misleading and also tends to trigger Goodhart’s law) it might even be more suitable to use a range. For example, we know that we usually complete anywhere from 18–25 story points.

This can be used not just for helping you roughly plan, but also for managing stakeholder expectations and avoiding low morale or burnout from significant and continuous overcommitment.

If you haven’t guessed already, my answer to the questions posed at the beginning of this article would be “is this really where you want to be spending your energy?”. We shouldn’t be concerning ourself so much with this metric. While velocity can be useful, it will never be useful enough to warrant a diversion of your focus from what really matters — value delivery. If you’re not delivering value to the customer, getting lost in velocity is not going to help.




An Agile Coach and dad who writes from time to time about his thoughts and experiences of work and life.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

The New & Old Testaments of Product

ProductDossier solves top 5 Project Management problems

The Art of Managing Multiple Projects Simultaneously

Define your product before you start building it!

How to Collect and Manage Feature Requests in SaaS

bug fix request

Competitive Product Analysis

Managing Project Risk

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Austin Mackesy-Buckley

Austin Mackesy-Buckley

An Agile Coach and dad who writes from time to time about his thoughts and experiences of work and life.

More from Medium

Run better meetings!

The Where (of Working)

The 7 Sins of Psychological Safety

Self-organized team- are we there yet? [Step 2/2]