5 ms·

Ugh the "velocity" one really hits home. A couple of jobs ago one of our project managers was constantly showing burn down charts (which, of course, never burne

Ugh the "velocity" one really hits home. A couple of jobs ago one of our project managers was constantly showing burn down charts (which, of course, never burned down); along with our "velocity". The funny thing is, because we were doing t-shirt-size/fibonacci, our velocity numbers varied so wildly that it was essentially a random number generator. Then we were required fit all our stories within a "budget" of our "average" velocity.. What are you supposed to do with the average of a random number between 0 and 200? Apparently a lot, because these insane numbers that had no actual tie to reality were used to determine how much we were allowed to "commit" to. Never mind that some months we'd finish 50 story points and some months 250 (because, again, the numbers were a fiction); we were always trying to fit things into 90 story points. Luckily all this useless theater only took up an entire day every two weeks. If you assume everyone on the team was making about $50 an hour, and it was about 6-8 people in attendance to these things, then it came out that this very dumb "estimation" process took 6 people * $50/hr * 6 hours... so about 1800 dollars. (Not including the project managers salary, which given that he drove around a very fancy luxury car, was probably a lot more than the rest of us). And people wonder why I don't take scrum seriously.

winrid 7y ago
To be fair, that's very poorly implemented. You should have reference stories for what is a 1 in complexity and the highest value should be low, like 13, which forces you to break things down and forces the PM to write better specs.
- overgard 7y ago
  We did all of these things. But we had this ridiculous Fibonacci thing where you would end up with a conversation like this: dev: well, this looks like it's somewhere between a 5 and an 8, so let's call it 6. pm: no 6 is not allowed, it must be either a 5 or an 8. dev: ok, lets call it an 8. Ok so that's a very plausible conversation, right? I'm sure we've all had it. But just that rule alone made the estimate on this story 20% off, just to satisfy a rule. I'm perfectly fine with that, if we're only talking about that one story. If we're both happy that this might go 20% faster or 20% slower than predicted, no big deal. But if you're going to include it in a larger rollup, you've included a very large error term with your number that you need to carry along with the rest of the calculations. Did you ever take a physics course in college? (A real one -- not one of the baby ones they gave to business and liberal art majors). If they were good, they probably made you deal with carrying an error term in your math. You probably even hated it because it was a pain in the ass to deal with, but it's also kind of important. If you're adding together 50 numbers that are all off by 20%-50% and chucking away the error term, your summary and conclusion are absolute garbage if you do not properly keep the error term included. Math is unforgiving like that. Presenting that absolute garbage as "data" is, in my opinion, professional incompetence. It just is. I guess the softening factor is that so many people do it that it's not an individual incompetence, it's a lack of competence in the profession itself essentially.
  - winrid 7y ago
    Well yeah, you don't have to use fib numbers. Not really sure why that's popular anyway. Personally I prefer being on a small team with excellent devs that don't require this kind of stuff. I built products that made many millions of dollars a year with just me, a PM, and one other dev with none of this stuff.

winrid 7y ago

To be fair, that's very poorly implemented. You should have reference stories for what is a 1 in complexity and the highest value should be low, like 13, which forces you to break things down and forces the PM to write better specs.

overgard 7y ago
We did all of these things. But we had this ridiculous Fibonacci thing where you would end up with a conversation like this: dev: well, this looks like it's somewhere between a 5 and an 8, so let's call it 6. pm: no 6 is not allowed, it must be either a 5 or an 8. dev: ok, lets call it an 8. Ok so that's a very plausible conversation, right? I'm sure we've all had it. But just that rule alone made the estimate on this story 20% off, just to satisfy a rule. I'm perfectly fine with that, if we're only talking about that one story. If we're both happy that this might go 20% faster or 20% slower than predicted, no big deal. But if you're going to include it in a larger rollup, you've included a very large error term with your number that you need to carry along with the rest of the calculations. Did you ever take a physics course in college? (A real one -- not one of the baby ones they gave to business and liberal art majors). If they were good, they probably made you deal with carrying an error term in your math. You probably even hated it because it was a pain in the ass to deal with, but it's also kind of important. If you're adding together 50 numbers that are all off by 20%-50% and chucking away the error term, your summary and conclusion are absolute garbage if you do not properly keep the error term included. Math is unforgiving like that. Presenting that absolute garbage as "data" is, in my opinion, professional incompetence. It just is. I guess the softening factor is that so many people do it that it's not an individual incompetence, it's a lack of competence in the profession itself essentially.
- winrid 7y ago
  Well yeah, you don't have to use fib numbers. Not really sure why that's popular anyway. Personally I prefer being on a small team with excellent devs that don't require this kind of stuff. I built products that made many millions of dollars a year with just me, a PM, and one other dev with none of this stuff.