top of page
Search
  • Writer's picturerahulmd

Estimates Will Always Be Wrong


Once you accept that estimates are actually guesstimates and that they will always be wrong, it is extremely liberating ๐Ÿ˜Ž


Let me share some insights and thoughts.


When estimating effort, very often what happens is that a senior person would take a quick look at the work involved and estimate it to take say 4 weeks.


Based on that, the work gets prioritised, it gets allocated to a team and they are told to finish it in 4 weeks.


Team have no clue how to finish it in 4 weeks. But this commitment has already been made and all plans have been made around this 4 weeks โ€“ including customer communications.


There are a 2 key issues with this approach:

  1. Estimate was done by someone who may have different/ better skill sets compared to the people who have to do the actual work

  2. While doing a back of the envelope estimate, the person may not have considered all the details involved in actually taking the capability to market

Anyway, the team start work with the 4 week target, but run into even more issues:

  • Infrastructure issues

  • Holidays and PTOs

  • Lack of clarity on who will use the product feature and what they are looking for

  • Scope creep

The last 2 are issues that could be addressed if you do "Elaboration" like we talked about in an earlier video.


Based on my experience working with product development teams for over 2 decades, here are a few best practices:

  • The team that is going to do the work should do the estimations. The senior person could provide a budgetary estimate. But the team who are going to do the work, should spend some time looking at the work during the elaboration cycle and they should come up with working estimates. They can then work with stakeholders to understand

  • What can be removed from the scope to reduce the effort

  • Alternate approaches to reduce the effort

  • Once the team gets comfortable working with each other, the quality of estimates will improve. This makes a really strong case for persistent teams!

  • Donโ€™t estimate in hours โ€“ it gives a false sense of exactness and accuracy It is easier to do relative sizing than exact sizing. Rather than saying user-story #1 will take 3 days and user-story #2 will take 4.5 days, it is easier to say that user story 2 will take longer than user story 1. A gamification of the estimation process which leverages this concept is Planning Poker. If "played correctly", it is an extremely powerful AND fun exercise with surprisingly good results! This is something we will explore in detail in next weeks video.

ย 

If you are facing challenges with estimations, give me a shout and I would love to chat :-)


21 views0 comments

Recent Posts

See All
bottom of page