In the Agile methods many suggest using something called Story Points instead of time when estimating the time a task would require for implementation. Rather than saying that it will take two days they would say it takes, for example, four Story Points. They then track what is called Velocity to see how many Story Points the team can complete in a week and suggest that about that many Points, let's say 20, is what the team can implement in a week.
I find this very awkward. Is it just a technique to hide the hours? Because, after all, most of us are still payed by the hour, and we also want to have an idea about the dates we might expect things to be finished. Story Points take this away. What would you say to the carpenter who you pay by the hour if he said he will have your bathroom done in 80 Story Points? He expects to burn about 20 Story Points per week, he adds. I would think he was a freak!
The only reasonable reason I find to use Story Points instead of Hours (or Days) is the notion that different coders may need different amounts of time to solve a task. With Story Points two coders may estimate a task to, for instance, four, while using days one might need two days and the other three days. That would implicitly say that coders are linear to each other in skill difference, since for the equation to sum up you'd need them to agree that the next task, estimated to two Story Points, would take the former one day and the later one and a half. Something I strongly disbelieve.
The more unreasonable reason is that as estimates are hard to do, you put a metric on them that is hard to understand to get away with them easier. If you say that something will take three days it's easy to see if you were right, while estimating it will take three Story Points will keep you safe. Who are to say how long a Story Point is? Hardcore agilists laughs at such a silly question.
I guess I'm missing something, but I have a hard time seeing the Point of Story Points. Feel free to enlighten me using the comment field!
p.s. I've never tried Story Points, so I might be totally wrong. It may be Gods gift to software developers. d.s.
I find this very awkward. Is it just a technique to hide the hours? Because, after all, most of us are still payed by the hour, and we also want to have an idea about the dates we might expect things to be finished. Story Points take this away. What would you say to the carpenter who you pay by the hour if he said he will have your bathroom done in 80 Story Points? He expects to burn about 20 Story Points per week, he adds. I would think he was a freak!
The only reasonable reason I find to use Story Points instead of Hours (or Days) is the notion that different coders may need different amounts of time to solve a task. With Story Points two coders may estimate a task to, for instance, four, while using days one might need two days and the other three days. That would implicitly say that coders are linear to each other in skill difference, since for the equation to sum up you'd need them to agree that the next task, estimated to two Story Points, would take the former one day and the later one and a half. Something I strongly disbelieve.
The more unreasonable reason is that as estimates are hard to do, you put a metric on them that is hard to understand to get away with them easier. If you say that something will take three days it's easy to see if you were right, while estimating it will take three Story Points will keep you safe. Who are to say how long a Story Point is? Hardcore agilists laughs at such a silly question.
I guess I'm missing something, but I have a hard time seeing the Point of Story Points. Feel free to enlighten me using the comment field!
p.s. I've never tried Story Points, so I might be totally wrong. It may be Gods gift to software developers. d.s.
2 comments:
In my understanding of relative estimation, one of the keys are that you need not to be "right about your estimates" (compare to your statement about being right about "three days" or not). Instead you try to be consistent, and let observation tell what multiplier to use if/when you want to convert to hours/days/weeks.
How do you learn when you said "three days" and it took four? Do you pick the task apart and analyze in detail, also accounting for disturbances. Or do you simply say - I should learn to add 35% on my estimates?
If the latter - you are already applying elements from relative estimation.
Hi Dan, thanks for your response!
Do you not have to learn from each task? I doubt you'll be estimating wrong in a certain percentage for every task - so you can't just make the story points "longer". In some task you may have under estimated, in another over estimated and in a third spot on. How would you learn anything from just seeing that you were 35 % off in total and make your story points 35 % longer if you'd need to convert them to days?
I'm not trying to prove that story points are wrong at all, I'm just trying to understand... and I just can't! Hence all this blathering. :)
Post a Comment