Every software developer has heard it: “How long do you think that will take?” And they are expected to respond with a single duration, to which they will be held accountable. This ignores uncertainty.
For many professions, the uncertainty is small enough that reasonable predictions can be provided. For example, a carpenter might tell you that he’ll take 2 weeks to build a fence. He doesn’t know that exactly, but he’s pretty sure:
With this little uncertainty, a single duration suffices.
Let’s look at some software development curves. I would guess most tasks look something like this (“I think that will take 2 weeks, but perhaps longer”):
Well that’s a different picture. What is the single duration here? 2 weeks? 4 weeks? There is a lot of uncertainty, and a single number is a gross oversimplification.
There are many different graphs that software developers might be trying to say.
“I’ve done that before, it’ll take max 2 weeks but I might find a shorter way”:
“That will either be really easy, or it could be a lot of work”:
And the carpenter case: “That will take about 2 weeks, I’m sure of it”:
Single numbers simply cannot describe these scenarios.
So what is the poor developer to do when asked the dreaded question? Head on over to uncertain.io and draw a probability distribution! This is a tool I built that helps communicate uncertainty.
A Fun Experiment
At a sprint planning meeting, have all the teammates independently draw their own probability distributions for a task estimation, and then compare. How uncertain are you about your uncertainty?