Estimating.

  • Why is it so painful, and why are we always wrong?
  • Why does the business need our estimates?
  • How can we be better with estimations?
Photo by Mikhail Nilov from Pexels

Why so much pain?

Let’s face it, estimating is painful because we are awful at it.

  • try to outline (in writing or in our head) a rough outline of the tasks/problems we need to solve,
  • Imagine roughly how much time each of those will take us, and
  • Add some time for any ‘unknown’ issues that might arise.

Why does the business keep pestering us for estimations?

To understand and answer this question, let’s try to get into the head of a typical ‘business person’ (product, operations, or whoever takes into their hands the roadmap).

how can we be better?

There are several schools of thought to answer this question from my exploration. Let me draw first a non-exhaustive list of them and then tell you what my recommendations are:

Break everything into tasks that are no longer than a day (SCRUM)

This approach works under the assumption that we can produce meaningful changes in a short period (a week or two) and that we can change priorities after each of those periods.

Don’t estimate (Shape Up)

This you might not be familiar with. The broad lines are that we do not estimate. We choose how much time we are willing to spend on an issue instead. If it remains unsolved after the allotted time, we scrap the project and re-define it. (do go read shape up for a better understanding)

Just add X%

I believe this to be kind of a no-no. It does not really solve the problem; you are just trying to account for uncertainty and unknowns, but you don’t account for them realistically by adding a fixed amount.

Recomendations (let’s estimate better)

So, as I hope I established, the need for somewhat precise estimations is not going away. How can you, as an engineer, get better at it?

Change the scale

The scale you use implies the precision you are giving. Let’s say that a project took you 17 days to complete, but you estimated it to take fifteen days. It would be more aggravating if your estimation was expressed in days instead of weeks.

  • hours
  • days
  • half-months
  • months
  • half-years
  • years (although if you are estimating in years, you have more significant worries)

Reflect on your estimations

When you finish a project, look at how long you estimated it to be. Look at how wrong you were and why. Try to reflect on what when wrong when doing your estimations.

Be upfront with uncertainties

If you don’t know how long something will take, but you are still pressed into an answer, try to give a couple scenarios for best, average and worst cases:

Conclusion

Estimations are not going away; business DOES need them, so we need to better speak their language and estimate within reasonable bounds.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Pablo Curell Mompo

Pablo Curell Mompo

Full Stack developer @ Seraphin, learned how to code @ Le Wagon. I love coding and plan to keep learning as much as I can about it :)