I'm a big fan of agile development. One of the key concepts that I like the most is story point estimation. The best suggestion I ever heard was to estimate the size of your stories in terms of gummy bears (at which point you can come up with possibly one of the best units of progress measurement, gummy bears / iteration), thereby making sure that nobody gets the impression that you're actually quoting any sort of real unit of time.
The exact opposite of this is trying to estimate stories in an agile project in terms of hours. All too often, even though these realistically are no more than "ideal hours", they are taken literally by everybody and if a developer doesn't manage to "burn down" 80 hours of development per week, they risk being told to either work harder or estimate better (it's often left ambiguous which solution is preferable), leading to what can possibly best be described as punishment driven development.
The unfortunate fact is, there is a certain inherent complexity to software development that's very difficult to account for accurately, so the best way of going about things seems to adopt an approach that assumes that people will at least estimate wrongly consistently (and use that consistency to come up with increasingly accurate velocity forecasts).
Or the development team learns to massively over-estimate and then take long lunch breaks. Thus allowing them to appear to be working hard AND hit estimates every time.
ReplyDeleteI completely agree but I've found it near impossible to get senior management to understand anything close to the concept of 'ideal hours'.
ReplyDeleteI agree with robert. If you stand with a stick on developers head to just meet the deadlines and nothing else not only the quality of code produced sux but they also start over estimating. In short look busy do nothing.
ReplyDeleteI agree with you on specific cards, still for business reason we need high level estimates.
ReplyDeleteBut in my experience Business Analyst are better to guess estimations than programmers or managers.
I'm not exactly sure about ideal hours as being the best way. But I have seen ideal hours work in regards to 4 hours per day as an ideal day.
ReplyDeleteAs a developer we don't "code" 8 hours a day.
You code.
You inspect.
You compile.
You check with coworker if it worked on back end.
You run test scripts.
Re-code.
Meetings.
Etc.
What has worked in terms of ideal man days is a 4 hour day and choose a baseline for your estimates. Something everyone understands.
I would disagree with uberto (above) though. How would a BA know better about estimates when he doesn't do the actual coding?