Velocity and the Sunk Cost Fallacy

2015 seems to be the year of Velocity.  For whatever reason both the haters and promoters have been out in full force for a lot of this year.

So there has been a lot of discussion about it recently in both coaching and client circles.

But one of the more surprising facts for people who are attempting Scrum is that not all work counts towards Velocity and that this is by design.

Groom to Ready, Sprint to Done

The majority of the time there are two strands of work going on inside a Scrum Team – Grooming and Delivering.

The Delivering is the part that most people are familiar and comfortable with.  Given a set of defined planned deliverables, how many were we able to complete to a pre-defined and fixed level of quality?

Scrum, being almost aggressively Agile however, only regards “Software as its measure of progress” and thus only counts Delivery of Software as progress.

Thus Grooming never really contributes positively to Velocity, but it can detract from it.1

The Upside Of The Divide

So if your skills primarily fall under what Scrum would class as “Grooming” then you may feel a little hard done by all this.  Where are your points!  You worked hard!2

Until you come to the realisation that in order to get points you have to estimate points.

Not so keen now are you?

Nobody really likes estimating, but there is a massive difference between an actual estimate “I think this can be done and I think this is roughly how long it’s going to take” and a forced estimate “I actually have absolutely no idea how long this is going to take, but you’re forcing me to give you a number, and so here you go, do you like this one? If not, I have others…”3

Much (but it has to be said, not all) of what we do in Grooming is rather open ended – Design, UX and so forth – and it also doesn’t tend to fit neatly into two week time-boxes.4

And this is precisely why Grooming doesn’t count towards velocity – it encapsulates the “fuzzy part” of Software Development.  

The stuff we have trouble quantifying upfront.  

It’s actually kind of cool.

Creating Pressure to Do Something™

So here is the interesting part.

Grooming doesn’t directly contribute to your velocity per se – but it certainly can affect it!

Think about it like this.

Imagine a Team that has a Nominal Starting Velocity of 20.

Now imagine that they only have 8 points of “Ready Backlog”

If they’re playing by the Strict Rules of Scrum5 then this means that even thou they have the “capacity” to deliver 20 points of “stuff” they only plan in 8, and thus their Velocity will only be 8!

This “sub optimal” Velocity has a simple cause6 – not enough stuff is “Ready” – and the only way increase Velocity is to get more stuff ready. (Which is what I’m assuming my hypothetical team actually spent their time doing)

Starting a Project the Scrum Way

So the upshot of this is that if you start a Project with Scrum – there is a natural pressure to stop navel gazing and start trying things.

Because it’s only when you start trying things that you’ll start generating the oh-so-popular velocity that all the kids are talking about.

If you’re working in two week sprints and spend 6 weeks “getting ready” then it’s going to look like you spent 6 weeks not delivering anything (probably because that’s exactly what’s happened – at least from an Agile Perspective)

Unless…

You don’t start doing Scrum until you’re Ready.

For a bunch of reasons a lot of places don’t use Scrum as described above.

Instead, even once they’re “post Agile” they still spend a lot of upfront time figuring out what they should do.  A lot of time “Getting Ready”7

Perhaps it’s out of habit or organisational convention, or perhaps it’s simply out of a deep rooted fear as to what an idle developer might get up to.  For the purposes of this post however, it’s sufficient to know that it’s been done.

Sunk Costs Sink Submarines

So now, imagine that instead of starting off a Scrum Project and feeling a subtle pressure to start delivering something and getting feedback on it8 instead there is a different pressure.

This pressure is the pressure to realise some value out of all the time and money that “we’ve” already spent.

If you spend 6 months and $500K before you start sprinting – then the sunk cost fallacy9 is going to drive you (or more likely your customers and stakeholders) to try and realise some value out of that exercise.  Whether or not that’s even possible.10

To make matters worse, your customer will also probably be positively allergic to non determinism and exploration by this stage; because from their point of view that nonsense should all be done by now

As such – they’re going to want to see a lot of Velocity and Story Points on everything.  We know what we want – deliver the damn thing!  Yesterday! MOAR VELOCITY!

Sailing the Seas or Hiding from the Waves

The bottom line here is that discovery and delivery are both equally important.  Delivery without discovery may well be pointless and discovery without delivery definitely is.

Scrum is far from perfect, but it does provide a mechanism whereby we can attempt to balance the two and successfully navigate our way across the choppy seas of complexity to Project Success Island.

But perhaps unsurprisingly it works best when embraced holistically and whole heartedly.  And part of that is coming to terms with embracing uncertainty navigating through it rather than trying to hide from it by ducking under the waves in the Discovery Phase Submarine.


  1. Considering that a well behaving Scrum team will never start work on Backlog Items that are Not Ready then it’s more than possible that such a Scrum team will be unable to plan a “Full Sprint” worth of work – and thus  their “velocity” is throttled by the amount of “Ready” work available. 
  2. The Problem here however is not Scrum, Velocity or even Story Points™ – the problem here is with your organisation’s understanding and misuse of Velocity. 
  3. Forced Estimates are interesting.  And by interesting I mean evil.  Because they’re just completely and utterly made up they tend to reinforce all the pre-existing stereotypes that many organisations already have regarding estimates in software development.  Most people are actually quite happy to agree to a completely new estimate if the original estimate was completely fabricated to begin with; as the objective here is clearly to supply a number, not the creation of a meaningful delivery forecast. 
  4. And trying to force it to usually ends badly. YMMV. 
  5. This phrase always makes me think of the golfing scene in Goldfinger.  Ironically, this is where James Bond cheats in order to win the game. 
  6. Which if you’ve ever been a jobbing ScrumMaster® is actually a nice change… 
  7. With the ironic position being that even after all this time, because “Scrum” has not been considered to have started, no Backlog Items are actually “Ready” yet. 
  8. Which also means starting to reveal some of our assumptions. 
  9. “Throwing Good Money After Bad” – the sunk cost fallacy or “Escalation of Commitment” is a cognitive bias which drives people to continue down a course of action simply because they have invested so much it in to date.  It is specifically a problem when the chosen course of action is now known to be the wrong one.  The fallacy itself prevents decision makers from even considering that they are taking the wrong course of action.  For a personal example – if you are at a fixed price all you can eat buffet – you are falling victim to the sunk cost fallacy if you eat well beyond your comfort level (especially if the food is not good) – because you feel the need to “eat your money’s worth”. 
  10. And guess who’ll be getting the blame if it’s not possible to realise any value… 

Leave a Reply

Your email address will not be published. Required fields are marked *