[IT Hacks!] Task Estimation
Engineers struggle with estimating tasks accurately during the initial days (or, at times, even after gaining experience). There are multiple reasons for the same.
- Not giving enough love to estimates: Often, estimates are asked in forums like stand-up meetings, sprint planning meetings, or 1:1 settings, where engineers experience pressure to provide estimates quickly. And instead, they end up doing guesstimates.
- Fear of facing tough questions: Engineers often feel that their estimates are too high and deliberately give a lower estimate to avoid the tough conversation with their team/manager.
- Too many assumptions: Engineers assume certain things about their task and provide estimates that don’t consider the task’s complexity. Usually, assumptions are driven due to a lack of business context, understanding requirements, or understanding of existing code-base.
- Relying on existing work: Often, engineers encounter a situation where they are told that the task is similar to other tasks that have been done in the past. Engineers reuse existing work and miss details specific to their tasks to save time.
If you can relate to any of the above or going to start your IT journey soon, I have got good news for you. Here are some tips to follow.
- Always take time to understand the task (both from a business and requirements and an existing code-base perspective). Refrain from assuming that you need to respond quickly when you are asked to estimate.
- Feel free to talk to Subject Matter Experts (SMEs) to understand things better. It will help you understand the complete picture.
- Always add some buffers to your best-case estimates. Remember Murphy’s law, “Anything that can go wrong will go wrong.” You can begin with 1.5x as the factor to add a buffer. For example, if your best case estimate is 2 days, share 3 days instead. You can always share both best-case and high-effort estimates to provide transparency.
- Divide the task into smaller milestones and estimate them separately. Doing estimation at a granular level (especially for tasks) will make you more predictable in delivering on time.
- Trust your estimates. If questioned, share the breakdown of the task by milestone and its corresponding effort to defend your estimates.
- Breaking tasks into milestones will force you to consider requirements and business context. If your change involves working in an existing code-base, do the code-reading to ensure you’re accounting for any surprises.
- Even if there is existing data to help you estimate, always revisit it to ensure you get all the information.
- As you gain experience estimating tasks, try to devise a checklist of things to look for during the investigation. This practice will help you when estimating greater efforts like a multi-month project.
Thank you for reading the blog. I’m writing a series of blogs to ease you into corporate life based on personal experience and mentoring new engineers. If you want to stay updated, follow me, and if you have a question, feel free to comment or write to firstname.lastname@example.org.