The Dev World – Sergio Lema

Some days ago, a teammate told me that he was unable to estimates his tasks.

He was asked to estimate the time needed to develop an entire cloud-based application with integrated AI, a polished frontend, and robust security. His answer? Three months. Not too much to scare the Product Manager, but not so little that he’d scare himself (let’s be honest, he was terrified).

For small tasks, it’s quite simple. But for tasks which will last more than a week, he’s completely lost.

If you’ve ever been there, don’t worry, you’re not alone. In this article, I’ll share the three steps I use to estimate complex, long-term tasks without resorting to random guesses.

Split the Task

You have to take into account that estimating a task is a task by itself. It’s not just dropping a random number in the air.

The first step is given a complex task to estimate, I must split it into as many small sub-tasks as possible.

A task is complexe when there is too many unknown parts. Splitting it into many sub-tasks, into many manageable sub-tasks, makes the whole task more concrete and organized.

Each of the sub-tasks must now be study and well understood. If some are still complexe, continue splitting it again.

Have a Reference Task

Now that all the topic is splitted into manageable tasks, I can estimate each one. But how?

You need a reference task. A reference task is something you’ve done before and know how long it takes. In fact, take a reference task that takes about one day to complete.

Having a reference task of one day, makes it easier to compare other tasks. Because I can compare smaller tasks (like half a day or some hours) and bigger tasks (two days or a week).

In my case, my reference tasks is creating a backend application with all the CRUD endpoints and a simple authentication system. Yes, this takes me about one day to complete.

Of course, my reference task evolved during my carrer. When I was a Junior, my reference task was adding a field in the database and to an entity of an object.

But as I adquire more experience, I need to adapt my reference task to always be about one day.

Estimate the Tasks

Now you have all the keys to estimate the sub-tasks you’ve listed in the first step. Comparing each one with my reference task, you can tell if it’s easier or more complicated.

How much easier or how much complicated is the sub-task?

I use the Fibonacci sequence for this: 1, 2, 3, 5, 8, 13, and so on. Why Fibonacci? Because the farther a task is from your reference point, the fuzzier the estimate gets. Using broad categories like “2 times harder” or “8 times harder” keeps things simple.

Why not using decimals?

Because estimating isn’t about precision. And let’s be real, if you’re off by a decimal, you’re still off.

Conclusion

Once, you’ve estimated all the sub-tasks, sum them all up, and you have the final estimation. Then, add a 10%-20% to handle unknowns (user tests, specifications read).

The important thing is that estimating a task, is a task by itself. I mean that it takes time, you need to split the tasks, understand and investigate each task… It’s not just giving a random number to make the Product Manager happy.

So, the next time someone asks you for an estimate, don’t panic. Break it down, compare it to what you know, and give a thoughtful response. Who knows, you might even sleep well at night.