Estimations: The Wrong Way to Provide One

Estimations: The Wrong Way to Provide One

Estimation: This article is a 5-minute read. (yeah, sure)

So, you’re at your computer, ready to start another day of coding and debugging, all hyped up by the coffee you brewed (or at least the machine did; you just took the mug, but who cares, it’s delicious anyway right?), only to find a bunch of estimation requests about some features you’ve never seen before!

So, what do you do? Well, you could try to do what’s outlined in them, see how much time it takes, and write that estimate! Genius! It can’t be more accurate for sure! But let’s be realistic, it’s probably not the way to do it.

So, what’s the next best thing? Shoot in the dark and say it’s going to take somewhere between no time and infinity! Also, not accurate, but fundamentally true! Not what they are asking for though.

Okay! Sure! Try the memory recall process. Try recalling something similar you did last time, how much time did it end up costing you? Urgh…. mmmh, it’s something you’ve never done before, and you can’t even remember what kind of coffee that machine brewed you 2 minutes ago, let alone the time it took last time you’ve seen an issue like this.

So, what do you do know?

providing estimations

Source: CommitStrip

Take Your Time

First thing, don’t rush. The time spent doing the estimate is part of the task. That’s why they are asking you that. It’s not a free and easy process, it costs time and thinking, but if there’s something you’re good at, that’s thinking! Right?

Take your time to read through all the requests that need to be estimated, and comprehend everything there is to comprehend about them.

Estimate What You Know

But again, most of that is gibberish, and you don’t understand everything! Well, bring it up, write that down and ask them to clarify it for you! You can’t possibly estimate something that you don’t understand.

Ask for Assistance

Ask a colleague to help you with the parts you are not that familiar with, but don’t over do it, their criteria and yours are different, you can’t work on their estimations, nor they on yours.

But let’s be honest, most of that, you did understand, right!? So you could at least estimate that to have something to show them, to begin with!

So estimate the parts you know about. How?

Break It Apart

Oh, you are an expert in breaking things… like that time you quick-fixed an issue on production only to see it going down, but lucky you had the backup to bring it up before anybody else noticed.

So break the requests into steps.

Every step should be easy to estimate. If it’s hard to estimate, then you should break it down too. Keep breaking it down as long as the answer to the question “How much time will I need for this?” is “I don’t know!”.

Once you are at the end of that line, you’ll be probably left with pieces of the task all scattered around with timings. That’s a good thing.

giving estimates
Source: Gerhard Healer

Round It Up

Now it’s time to group up those small estimates and put them together. You can do it as a list, and near every entry set the range of time it would require. Something like:

  • Taking the mug [0.5h – 1h]
  • Washing the mug [0.25h – 0.5h]
  • Brewing coffee [0.75h]
    • Loading the machine [0.25h]
    • Waiting for the brewing process [0.5h]
  • Cleaning the machine [1h] (who has the time?)

Final estimate [2.5h – 3.25h].

Please note the Cleaning machine section which is related to cleaning your code after the task is completed. That’s key in every development process as I mention here.

Providing a breakdown like this as a final estimate is a great way to let everybody know what’s the pain point in the task being estimated, so they can reconsider parts that are too demanding in favor of other features.

Be Generous but Not Greedy

Now that you have the realistic estimate it’s time to give yourself some space; after all, sometimes, services get stuck, the cache is making you dizzy, bugs are sprouting everywhere, it’s just not the day for you… so it’s good to have some breathing room.

To achieve that, it’s good to locate the riskiest sections of the estimate and add some breathing room. Just remember that adding a few minutes in different parts is going to result in overestimating the whole thing, so you might want to consider the right amount of time to add at each step.

Don’t be greedy, after all, despite your lack of sleep, bad mood, and procrastination habits. You’re a professional person, and it’s good to be as such as long as possible.

Conclusion

It didn’t take you 5 minutes? Sorry, I’m a slow reader, and even worse at making estimations, so if you know a better way, let me know in the comments.

Aleksandar Pavlov - Senior Software Engineer
Aleksandar Pavlov
Team Lead and Senior Software Engineer