The Task
How good are you at estimating how long a task will take? More importantly, how good are you at estimating the relative difficulty of different related tasks? Can you say, with some degree of certainty, if one task will take twice or three times as long as another task? Given a list of tasks, can you give an accurate estimate of which one will take the longest?
Here's a simple exercise we can try to evaluate your estimation skills. I will show you a picture of a sailboat. I need you to look at the picture and answer three questions:
- How many sails does the boat have?
- Is the boat sailing toward the left or the right of the picture?
- In the picture, is the wind currently blowing?
Based on this description of the task, how long would you estimate the task will take? Which sub-task will take the longest? Will any sub-task take twice or three times longer than the others to complete?
Do you have your estimates?
Are you sure?
Ok, then, I'll show you the picture...
... no peeking ...
... it's coming ...
... in just ...
... a ...
... bit ...
The (Big) Picture
So, how'd you do?
That bad...eh?
The Problem With Estimates
What went wrong?
You might blame the inaccuracy of your estimates on being given incomplete information, but that's the very nature of an estimate, isn't it? You don't have to estimate how long it takes to bake a cake, because you have a complete recipe. If you are making an estimate, it follows that some information will be missing.
But what about your estimates of relative difficulty? Imagine your manager asks you how long each sub-task will take, and you respond that they should all take about the same amount of time. Then, after a day of staring at the picture, you go back to your manager and tell them that you'll need another day to finish the first sub-task. Based on your initial assessment of relative difficulty, your manager would justifiably freak out, expecting that what was initially estimated as a 5 minute task will now take 6 days!
Of course, that's not true. Once you can see the boat, it will only take 5 minutes to complete the task...
The Rate-Determining Step
One of my favorite topics from Chemistry is the concept of a reaction mechanism. If you have some chemicals that are reacting to form something new, you can dream up any number of different steps that the chemicals can take to get from start to finish. For each such mechanism, though, there will always be a bottle-neck or "rate-determining step". Regardless of whatever else might happen in the reaction mechanism, it is the rate-determining step that tells you everything about how fast or slow a reaction will proceed.
For any programming task, too, there are rate-determining steps: "once we figure out how to make a successful call to the API, everything else will be simple" or "we need to design the data model first, then we can get to work using it" or "if we can get the d@*! thing to deploy, then all the features should be working". Once these steps are complete, estimating how long everything else will take becomes much easier.
So, next time you have to estimate a task, in addition to giving a best guess for how long everything will take, try to identify the rate-determining step. You may not identify the correct one at first, but that's OK! You likely didn't guess that the rate-determining step for the task at the start of this was "making yourself go just a bit wall-eyed".
What's important is that, if you identify a new rate-determining step, you should communicate this to your manager and your team. This will accomplish two things. First, your manager won't have to freak out about how far off your other estimates might be, as there is only one rate-determining step. Second, your team will be able to come together and work, as a team, to clear the rate-determining step so that everyone can be more productive.
Top comments (3)
This is basically about realizing the difficult tasks (difficult in sense of not knowing yet how to solve it, e.g. from a technical perspective). If you know it, it is possible to "imagine", what the solution would be like. This is also a big difference, if you think about a Junior Developer and a Senior Developer. The former can try to estimate, but the main issue is usually, that a lot of things have to be researched and learned, which is totally fine, while the latter is more likely to know everything, which is needed to get the "imagination" of a possible solution.
It highly depends on the people, who are estimating.
While I agree that identifying what will be the difficult tasks ahead of time is a valuable skill that quite often does differentiate Junior from Senior Developers, the concept I'm trying to relate here is subtly different. More than just being able to identify the difficult tasks ahead of time it is equally important to recognize when one of the "unknowns" for a task reveals itself to be the difficult task.
Too often I've seen devs (even very senior devs) or entire teams set off on a "death march" to inevitable failure just because their initial estimate didn't capture the actual most difficult task, and they failed to adequately re-evaluate/re-estimate once they had that additional information.
Estimates are a waste of time. Avoid