|
Top-level
 @Alice What timing! We're trying to implement more Agile processes at work and just finished the training module that emphasized how much we need everybody to participate in the estimation process no matter how little you know about it. "Okay, since I know nothing at all about the problem domain I'm going to estimate it takes me 2 weeks just to study it and a month to implement anything at all. No, I don't believe that's accurate but I don't have any relevant info." 10 comments
I practice the Montgomery method. Under-promise and over-deliver. My estimates are conservative, and most of the time I get it done, and then some. If there's an unforseen issue, I still get it done, I just don't have enough time to go above and beyond.   @gooba42 @Alice The purpose of agile estimation (well the way I've generally used it) is not so much to produce estimates as to identify what the team knows and doesn't know, what the risk factors are, and whether there is a shared understanding of what needs to be done. For example, if different people produce different estimates that might be an indication that there is need for more knowledge sharing or making a ticket for study or something. I thought Agile meant getting out of the way when the brown stuff collides with the fan-blades. @HereToChewGum @gooba42 @Alice Agile means a whole lotta things and you don't always get the best ones @HereToChewGum @gooba42 @Alice Usually you might need a very large audience to find the one who is like <whoosh what just went over my head?>. But if I'm around one is enough. I can be pretty reliable that way. |
Gregory's Server
@gooba42 @Alice The error margin is supposed to statistically even out over lots of tickets. Which would work if the estimation errors were randomly distributed, but they never are, because software engineers are incurable optimists. So your best bet is to take the median and double it. That's usually a solid estimate of the actual costs.