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).
- Posted by: Marc Levin
- Posted on: December 07 2010 17:55 EST
- conversion problem by P P on December 08 2010 10:17 EST
- Shouldn't that read: "80 hours of 'burn out' work per week"? by Corba The Geek on December 08 2010 13:34 EST
- Punishment driven development by Wesley Hall on December 09 2010 05:51 EST
- Punishment driven development by Saad Khawaja on December 10 2010 01:31 EST
I disagree. The whole "gummy bear" unit idea is the part I tend to discourage (or advice against) in SCRUM organized teams and projects. In my experience, developers will still do the "gummy bear to hours" conversion in their heads so why add the extra layer of obfuscation. We're not developing in a vacuum so I prefer to use a unit of measurement that has meaning and relevance outside of the SCRUM-team as well.
Also, time = cost and I don't think it's a good idea to muddy up that fundamental truth. The important thing is to track velocity and understand what that concept means. When your velocity falls it's much easier to go to your stakeholders and your upper management and say that "our real output has gone from 200 hours/week to 170 hours/week so you need to improve your specifications or stop bugging us with out-of-band requests". Trying to make a rational argument to an "outsider" based on gummy bears is generally not very productive.
I've found that developers gain accuracy with their estimates as iterations progress. The immediate feedback of the daily burndown lets them know if they're high or low on their estimates. Maybe people's expectations are too high? After all, they are call ESTIMATES! I really don't see the point of using irrelevant measures like gummy bears.
Yeah, I dislike these virtual units also. We fix the problem of the 'business' not understanding the complexity of software development estimating by using a language they don't understand. Effective, but not professional.
The purpose of velocity is to track the amount of work done, not how many hours were spent in an iteration. For example developer x and y spend 8 hrs eating bananas, but developer x may eat 50 and y may eat 100. The measure of progress is not that they spent 16 man hours, but how many bananas they were able to consume.
Estimating in hours(absolute terms) is more difficult then estimating relatively in virtual units. The business should care about the rate of work being done over a period of time. And would like to know given the current rate how quickly will the product backlog burn down.
One should always relatively estimate the stories and derive hours, and use this process to fine tune estimation. At some point you will be able to translate your virtual units to hours, but it will be
I like the title PDD, bring out the whip!