4 ms·
That's the biggest danger with estimates, that you're being held accountable for a padded guesstimate. One way of avoiding this is to give estimates in ranges o
by omouse 12y ago
That's the biggest danger with estimates, that you're being held accountable for a padded guesstimate. One way of avoiding this is to give estimates in ranges or with +/- attached:
"It will take 2 days, + 5 days, - 1 day" <-- that shows a lot of risk
"It will take 1-2 hours, + 3 hours - 0.5 hours" <-- again, showing that there's some risk
Or you push back and tell them to give you some time to form a better estimate or that you will give them an estimate update as soon as you know more.
The issue is that most software developers are not trained in how to estimate and in how to deal with these time/cost boxing scenarios. We don't attend a class like managers do on how to deal with situations like this. We have to learn as we go along.
I highly recommend Steve McConnell's Rapid Software Development, fantastic book, it has a chapter on estimation and how to deal with client's and boss's that ask for estimates.
- sime 12y agoHe also has a whole book on estimation called Software Estimation: Demystifying the Black Art. It's a great read as well.
- omouse 12y agoBought it and recommended it to someone already, thanks for the suggestion!
- blt 12y agoIn my opinion, if someone is asking you for estimates on 1-2 hour tasks, that person should kindly remove him/herself from the software development industry.
- gknoy 12y agoYou could simply say, "I don't give estimates in under 3-hour increments, because there are inevitably other fire-extinguishing and support activities that interrupt even the most trivial tasks." Sometimes I get interrupted with "Alice needs X added to Y right away", or "Bob needs reassurance that this is working as intended in the original ticket" -- no problem. Other times, one might lose productivity to things like, "Java update broke our GWT compilation toolchain completely". It helps if your manager knows that such interruptions happen, too. I also am a fan of overbudgeting and then revising later once I understand the problem better.