3 ms·

I like doing detailed estimates, because it helps me decompose the problem. This gives me a chance to get a good understanding of the problem, and get up-front

I like doing detailed estimates, because it helps me decompose the problem. This gives me a chance to get a good understanding of the problem, and get up-front clarification from the customer on even the smallest details. The side benefit is that it also gives me an idea of how long the project will take, with regards to the knowns. Then I triple that as my estimate to cover the unknowns, with a bit of wiggle room to spare. Then I stick to my guns with management (a luxury, I'm aware), and the customer's expectations generally get set accordingly. So, while it may not be an exact estimate, I have an accurate understanding of the requirements up front, and the customer usually ends up happy on the back end.

haakonhr 5y ago
I think this is key. I often struggle to communicate that estimating certain tasks essentially means starting them and that giving a proper estimate might require a day of work (or more), e.g. when getting familiar with a new API or working towards some performance criteria. However, this is rarely taken to heart so most of our estimates are more "if you actually want an estimate it will be essentially random from the top of my head", which satisfied the product owner for now and defers the dissatisfaction that comes when said estimate turns out to be inaccurate.