Need an estimate? Stroke the goat…
Two of my colleagues thought it would be hell funny to come up with a magic eight ball type tool for coming up with project estimates. They’ve called it the Estimate Goat. The site was born out of frustration from too many projects where estimates for effort were poorly made by ill-advised project stakeholders. So if you find that you are pulling numbers out of the air for your projects, then why not give the Estimate Goat a go today.
When I worked at Thoughtworks, it was actually the first company I worked for that I had a project manager that really pushed for accurate estimates. It is quite different than what I generally run into.
At my current posting I have one co-worker (on contract) that has a one-size fits all estimate (2 weeks). Even if he knows the project will take 12 weeks, his estimate is 2 weeks, then 2 weeks, then 2 weeks, then 2 weeks… everytime the VP (who he gave the estimate to comes by to ask — how long now — 2 more weeks). At one time he actually tried to give accurate estimates but the VP always came back and said — too long — so he adjusted the estimates to meet the expectations.
Craig Cruden
23 Aug 07 at 12:08 am
I think this just typifies why software engineering is still struggling to make the transition from unplanned endeavour to mature, repeatable discipline.
Dave
28 Aug 07 at 6:41 pm
The Estimate Goat is friggen hilarious! Now all it needs is a way to submit more outcomes for “will it work” and “should I stick with the project/job”.
On a more serious note…
I think that one of the biggest problems is that as project team members we’re giving estimates like “2 weeks”. “2 weeks” isn’t really an estimate, it’s a guess (and in the case of Craig’s co-worker a funny but sad guess).
An estimate should look more like “1-4 weeks” or “3-5 days”. It really should be a range. One big downside of single-point estimates is that the estimate is likely to be treated like a promise. On the other hand, giving a range opens the discussion of what could happen (risks) that would push the effort towards the worst case end of the estimate or bring it in towards the best case end.
Another nice thing about ranged estimates is that when you are asked to estimate something with poorly defined requirements you can give wide ranges to communicate the uncertainty. Well defined, believable requirements get estimates like 5-7 weeks whereas poorly defined, nebulous requirements get estimates like 4-20 weeks.
Bruce P. Henry
29 Aug 07 at 3:17 am