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).