So... the title hooked me, because this has been an opinion I've had for a while, but have been reluctant to share out of fear of being told that I "just don't get it" or worse, being called an apostate... or WORSE... an old guy who is set in his ways and can't be taught new techniques and new tricks. All of which, well, I *am* open minded to as possibilities. I'm 41 and the first time I put my hands on a keyboard to write code was 1983-ish and it was a Wang, my first language was line numbered BASIC and my second was COBOL, both on an NCR mainframe. So yeah... there *is* a chance I'm just an old dog who can't be taught new tricks.
And when I started reading, I was thinking to myself, "for a person who came to the exact same conclusion I did, I don't think he knows what a 'story point' actually is, or why they are just wrong, but I still think I like this article." Then you demolished the myth of "story points aren't ACTUALLY time estimates, they just measure complexity!" and we were 100% on the same page again.
This is EXACTLY why I think story points are bogus! Even worse, coming up with an estimate via committee (like the poker system) is INSANE. If developer A is convinced something is 10 hours and developer B is convinced it is 40, and their poker game results in them compromising on 20... and then developer B gets the task... they are now held to an estimate that they were certain was nowhere near right. And since when do developers OVERestimate by 50%? But the poker game forced B to compromise on an estimate that they *knew* was no good.
Now put yourself in B's position. Why *should* you actually meet that estimate? It's half what you said it should be. If you said 40 hours, it took 50, it's still within the realm of "not so awful" as far as actual vs. estimate in this industry, and if you put in some overtime it's still done in a week so no one is going to be too mad, right? Sure, we can argue that. But let's say we use this committee decision, and since the committee said 20 hours, they give B another 15 - 20 hours of estimated work to do that week. Even if B's original estimate of 40 hours was perfect, and the other committee estimates are perfect, B is now committed to 55 - 60 hours of work RIGHT THERE and that's before the possibility that the additional tasks are also mis-estimated. Either B is going back and saying "gee, I guess we're missing 50% of the story points this week!" or B is on track to work 80 hours that week *through no fault of their own*. How long until B starts looking for another job? How long is B going to be happy saying, "gee, my estimate was 100% accurate, but because we use this poker system I'm working 60 - 80 hours every week because everyone else has over-aggressive estimates and I am forced to compromise with them?"
I just can't help but think that not only are story points a fraud... because they are a roundabout, opaque was of just giving a time estimate... and that the way Agile teams use them takes this fraudulent estimate and makes it even worse by using various committee systems to come up with it, in a way that takes the responsibility for meeting the estimate away from the developer.
In a sane system, B says "40 hours" and gets the task, B does it in 40 - 50 hours, B's boss says "wow, B is really great, we assign them tasks and they get done on time!" and B maybe tightens up their estimates a bit so they squeeze that 20% margin to 10% or better so they can have a spot-on 40 hour week. Which is the exact process I used to do when I was running teams... we assigned each developer 28 - 32 estimated hours of effort each week (we had about 2 hours of meetings total each week, and I tried to make sure they had an 8 hour day measured from arrival to departure with a few breaks, and we knew production bugs found mid-week (we did 1 week sprints) would sometimes interrupt someone. And each person would be assigned items based on their experience level and specialty, and then do an estimate on their own, and we'd basically fill their time bucket more or less and call it a day. And if people were working too much, it was either because we had a ton of surprises, or they did a poor job estimating, and that was their personal responsibility. And because people knew that those estimates came from nowhere besides themselves, they took responsibility to meet them and learn to do a better job in the future.
J.Ja
