How to estimate the time required for a task

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

And why is Agile estimation called Planning Poker? Let me remind you that poker is gambling.

So why do time estimations feel like gambling?

• It feels like gambling because you have very little time to estimate many tasks.

• When I ask you how long it would take to build a bridge and give you only 5 minutes for that estimation, the only option for you to provide a number within the given time is to gamble.

• Providing accurate estimations depends on the time you spend on the estimation process. The more time you dedicate to making the estimations, the closer they will be to reality.

Why is it better to give a slightly longer estimation than a shorter 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 believe it will take X time, consider estimating it as 1.5X to 3X instead..
2. The accuracy of estimations is directly proportional to the amount of time spent on them. If you don’t have adequate time to estimate properly, it’s important to clarify that the provided time is not a commitment but rather a rough guess. However, when sufficient time is allocated for estimation, the actual time required to complete a task can typically range from X to 1.5X.
3. It is crucial to ensure that the task is completed on time and that the user receives the promised feature. Therefore, it’s important to be meticulous with your estimations. It's better to overestimate than underestimate; delivering earlier is always a bonus, but failing to deliver on time can negatively impact both the user and your team.
4. When asked to reduce the estimated time because the task seems small, it's important to calmly explain the following: The task may appear small, but it could involve implementing underlying infrastructure.
   • Context switching takes time and impacts productivity.
   • Thorough testing is necessary to ensure quality.
   • Small tasks can require changes to the data model, potentially causing cross-application refactoring.
   • Dependencies on a UI components library might demand additional context switching and testing.
   • UI components need to be tested across different browsers for compatibility.
   • Writing clean, maintainable code aligned with style guides and best practices requires time to avoid technical debt.
   • Reusable components should be created for tasks used across multiple locations to reduce future duplication.
   • Performance considerations must also be addressed to ensure efficiency.

The most important goal is to create solid, well-structured code that is easy for your teammates to read and extend. A strong infrastructure ensures that bugs can be fixed efficiently and avoids the need for constant refactoring when working on someone else’s code.

Writing good code is fundamentally different from creating quick patches that only work in specific cases. Good code takes time, but in the long run, it significantly reduces the effort required to fix bugs and accelerates the development of new features.

One important analogy to remember is: "A woman cannot give birth to a child in less than nine months." Some things simply require time to be done properly.

Happy coding, everyone!