3 ms·

> I definitely do the "manager doubling" when it comes to estimates. If I think it'll take a month, I estimate 2 months to my boss. If I have to report several

> I definitely do the "manager doubling" when it comes to estimates. If I think it'll take a month, I estimate 2 months to my boss. If I have to report several levels up, I multiply by 2 for every level. Hah, I like this. Every level up that sees it is also a potential for more scope creep, as each person will have their own vision of what's being produced. One of my favorite estimating guidelines from a mentor was that development tasks are either 2, 4, or 8 hours. If it's more than 8 hours it can be broken up into smaller tasks.

nstart 11y ago
The most common time the 8 hours policy breaks down (insert rage face here) is when going bug hunting on non straight forward bugs. I just got out of a 5 day bug hunt where the fix was literally changing a 10 to 40 (so, 1 character change). The debugging process to realise this was painstaking elimination of possible causes. I eventually stumbled on the root cause by mistake when I out of frustration just switched an unrelated boolean flag to see if I could get a laugh out of what happened next. These tasks can really screw up an entire dead line. I have a policy on those which is two steps: 1) Daily report in the morning SCRUM style of what was tried, and what's going to be tried next. 2) After a full working week, reassess everything and try and understand where you are going with this. Rinse and repeat. Basically the estimate is set at 5 full working days whenever you work on an obscure problem. But it's not a hard deadline. It's just a hope that it'll work out by then and a mild mental aid of giving something to work towards.
- dagw 11y ago
  It takes 8 hours to implement the feature. It takes a lot longer to make it actually work.