2

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?

Improve this question

2 Answers 2

Reset to default
8

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.

Improve this answer
8
  • 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.
    – John V
    Commented 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.
    – nvoigt
    Commented 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.
    – John V
    Commented 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.
    – nvoigt
    Commented 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
    Commented Mar 15, 2019 at 10:34
1

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.

7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development (Video)

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.

With this in mind I will try to answer your question:

What is the main purpose of velocity?

  • A signal of a trend of slowing down, maybe due to accidental complication. Something worth investigating
  • Assist with sustainable pace, your Sprint Backlog (forecast) contains a realistic amount of work
  • You know when to stop refining stories, e.g. ~2 Sprints into the future
  • Give very uncertain predictions. In my experience long-term prediction are off by 25% to 500%. Worthless.

In relative short and simple projects it might be accurate enough for predictions. In more complex and bigger projects, only if the teams have mastered technical excellence, but even great developers let accidental complication sneak in.

Velocity is a proxy metric, not an actual metric. It keeps you in an illusional dream bubble, until it pops and you see it was a lie.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.