# If Velocity should not be used for future estimations, what is it good for?

I have read the following thread and a few articles sharing the same view - velocity should not be used for predictions.

This has somehow rocked my world, as we often look at the velocity, remaining backlog work and then estimate the end of a project. If this is wrong, what is the main purpose of velocity?

Sorry, but that is not what the article says at all. The purpose of measuring the past is predicting the future and no one in that threads claims different.

What is claimed though and I absolutely agree is that you should not predict the future in absolute, precise, single values.

If I go from one city to the next by car, I will say "I'll be there in 2-3 hours". And people understand that to be an estimate. I might arrive in 1:45h. Or 2:30. or maybe even 3:20h if it's worse than expected. It was clear from the start that it was an estimate from the plain fact that I gave a range.

Now if you tell people you will arrive by car at 15:48 (because that is the exact average over all your past trips added to the exact time you plan to leave), then they'll be disappointed if you are 5 minutes late. Or 10 minutes early. You said 15:48, why didn't you keep your promise?

So units matter. Saying it takes "about an hour" is different from "59 minutes". The first is a rough guess and people get that from the language, the second is perceived as precise and accurate and people will hold the person accountable for that.

So if your velocity is measured and you have 30, 50, 40 in three sprints and 300 left, do not average it all and claim it will be done in 7½ more sprints. That implies precision that is just not there. The truth is that the data means it should be done in 10 sprints worst case and 6 sprints best case. So go with that and say "it should be done in 6-10 sprints". The wording alone already implies that it is an estimate, not a precise measurement.

• From the second of that article paragraph: Velocity is a good tool to reflect on current status, but it’s absolutely not suited to determine future status. Mar 15, 2019 at 9:38
• @JohnV Don't pick a single sentence and put it on a pedestal as the absolute truth. Read the whole thing. Hint: the part marked in bold is probably the part the writer thought most important. Mar 15, 2019 at 9:40
• I am trying, but there are statements like the following: But under no circumstances - unless you’ve bought into one of the later-day flavors of Agile (that are little more than dressed-up, big-batch waterfall) - is velocity, or any measurement of the present (or recent past), sufficient for predicting project duration. Mar 15, 2019 at 9:42
• Yes. Notice it's "not sufficient" now. Already toned down from the previous "not suited". And if you read the whole thing you'll see that he says exactly what I said above. Don't use velocity as a single precise number. Because it's not. Mar 15, 2019 at 9:47
• I really like your explanation of velocity using the travel time in a car, it is so clear that I will probably remember it for ever. Thanks @JohnV
– Bart
Mar 15, 2019 at 10:34

Estimates and Velocity (most often) do not take accidental complication into account, making it worthless for long-term predictions.

The cost of a feature is a combination of essential complication + accidental complication.

• Essential complication: how hard the problem is to implement
• Accidental complication: How much corners we cut, deadline pressure, or the number of bad design decisions because we are not so good at our jobs.

Now for most feature predictions we only take essential complication into account. We compare complexity of a new feature and compare it to the complexity of already delivered features. For example with story points. But in reality accidental complication dominates the implementation effort compared to the complexity of the feature standalone.

This is explained in this great short video :

The cost of your feature has almost nothing to do with how hard it is, and almost everything to do with how much your design sucks.

So relative estimates completed over time (velocity) have no prediction value for future work if you have a lot of accidental complication. And trust me most teams have, unless they refactor rigorously and or apply XP practises continuously.