How to estimate the time for a task

Is task estimation is gambling? How do we develop good code with correct estimation time?

And why Agile estimation called a planning poker? Let me remind you that poker is gambling.

So why is time estimations feel like gambling?

• It feels like gambling because you have very little time to estimate a lot of tasks. When I ask you how long it would take to build a bridge, and I give you 5 min for that estimation the only option for you to give me a number in the given time is to gamble.

• Giving close to reality estimations depends on the time you spent on the estimations process. So the longer the time you spent on giving estimations, the closer to reality it will be.

Why it is better to give a slightly longer estimation than a smaller one?

When you give smaller estimations, and as usual in reality, it will take longer, you always feel that you are underperforming. This feeling is not good for you or for your team.

So what can you do to estimate tasks correctly:

1. When you are given a short time to estimate a task, and you think it will take X time, give it 3X.
2. Explain that correctness of estimations is directly proportional to the time you spent on estimations. If you don't have time to estimate properly, explain that you are not committing to this time, but it is just the gambling number.
3. When you are asked to cut the time since it looks too long for such a small task you should explain very calmly that:
   • It looks small, but under that, there is an infrastructure to be implemented
   • There is a time for a context switch
   • There are tests to be done
   • A little task can have changes in the data model, which can cause refactoring cross application.
   • The little task can be dependent on UI components library, which will require additional context switch and tests.
   • In the case of UI components, you also need to check it on different browsers.
   • Writing good code using style guides and best practices takes time since we don't want spaghetti code.
   • In case the component is used in several places, we want to refactor and create a reusable component only once, then use it in all the places.

The most important is that you will create good solid code that is easy to read and easy to extend by your teammates. Good infrastructure makes it easy to fix bugs and will not require refactoring every time you try to fix something in someone else's code.

Writing good code is different from creating patches that work in specific cases. And good code should take time, good code in the long run will reduce fixing bugs and reduce time to create new features.

One important thing to keep in mind is that "A Woman cannot give birth to a child in less than nine months."

Happy good code to everyone!