Better Estimates by Embracing Uncertainty


Existential philosophers tell us that uncertainty is a fundamental given of existence.   But uncertainty is also something which we often find to be undesirable and we seem to spend a lot of time trying to rid ourselves of it.

Friedrich-NietzscheBut often the solution is not to rid ourselves of uncertainty.  Instead, it is to embrace it.  As Nietzsche said:

“Not doubt, certainty is what drives one insane.”

I am sure that a lot of software development teams will relate to this quote when considering estimation – that great attempt at removing uncertainty.


Sprint planning: after a session in which goals are stated, user stories defined and story points assigned using various elaborate calculations, a final cut of what work the team will commit to doing for the next sprint is declared.

As a scrum master, coach or some kind of delivery manager, you might wish to make a final sense check by counting up the story points and comparing the total with the team’s velocity, allowing the opportunity to adjust accordingly.

Colour Print


Perhaps you might ask the team: “do you think you can get all this done in this sprint?”.

Or maybe you will focus on the key goal and consider whether this one goal is attainable.

In my experience, rarely do any of these methods protect very well from overcommitment. In fact, I have found overcommitment in a sprint is almost always the case. I don’t know for sure why there is such a strong tendency to overcommit, but my feeling is that we are highly conditioned to pressurising ourselves and to avoid looking like we are doing nothing. Being busy, rather than effective, seems to be so highly valued, that no matter what measures you take to avoid overcommitment, being busy wins every time.

Overcommitment is not sustainable



The problem with the busy obsession, of course, is that we stop working sustainably. Tech debt and burnout go up, while quality, motivation and morale go down.  In fact, what is the point in estimating the work if not to weigh up the amount of effort to spend on feature development versus maintenance and upkeep?

But anyway, this is not a post about the important principle of sustainability.  Although overcommitment is indeed a problem because it violates the principle of sustainability, my point is that overcommitment is very common and a difficult habit to combat.

Be subjective

So what can be done to combat overcommitment? I have drawn inspiration from the book “How to Measure Anything” by Douglas W. Hubbard.  One technique which Hubbard employs is one which uses subjective percentage certainty.  By asking someone to give their own subjective degree of certainty of the likelihood of a given outcome, Hubbard found that he was able to shift people to a more honest and open estimation.


From a psychological perspective, I suspect that this technique shifts a person into a mindset similar to one in which he or she is asked to bet on an outcome or, at least, to set the odds.

The sort of percentage that is indicative of an accurate estimate will typically be around 90%. If it is lower than this, then this should tell us that the people estimating feel that the estimate is too tight. If the percentage given is closer to 100%, then it may be a sign that the estimate is too generous.

Accept that nothing is ever certain

What I also like about the subjective percentage certainty technique is it successfully gets past those situations in which people refuse to estimate due to there being too many unknowns.

Instead, we accept as a given that being 100% certain is impossible and we don’t even bother pretending to be so.  We cannot even be absolutely certain that, as a team, we could deliver a single one-point user story within a sprint, since it is theoretically possible that there could be an outbreak of the bubonic plague which took out the whole team … for example.

But we can say that this is highly unlikely and reflect this in our percentage certainty of success (maybe 99.9999%).  If there are many unknowns or dependencies, we can give a low percentage. So rather than simply saying “I don’t know”, we can say “I am only 10% certain that we can do it, because that piece of legacy code in my experience is a complete nightmare to deal with”. At this point we can adjust what we aim to do in such a way as to increase our probability of success.



So, next time you plan a sprint, try asking everyone: “how certain are you, as a percentage, that you will get this work done in this sprint?” I am 90% certain that the team will give a figure less than 90%.


Haran Rasalingam is the Lean Agile Coach at Trainline.

You may also be interested in reading:

This entry was posted in Agile, Psychology. Bookmark the permalink.