I recently came across this agile estimating experiment
Walton. The article is quite old now but I still found it very
In recent years, I've had quite a fascination with
the concept of velocity
To be honest, it took me quite a while to really
get this concept! But once I understood the statistical nature of it -
once the penny finally dropped - I have loved it ever since!
my experience, it really is the
secret to delivering on time
- the holy grail of software
development projects for decades. And better still, it's so easy to do.
The biggest obstacle of all seems to be
explaining it to people without sounding completely mad. It really does
sound quite whacky. Some weird development technique practiced only by
people with long beards and sandals! :-)
But it's worth doing.
Because it works!
Lance's experiement is interesting because he
is using statistics to show evidence that estimating user stories in
points was just as accurate as estimating tasks in hours. And in his
case at least, it was.
I can remember trying to convince some
teams to try estimating in points. With so little information, they
were convinced that estimating user stories in points wouldn't be
accurate. The truth is they were probably right. Estimating in points
isn't accurate. My argument for using points was somewhat
counter-intuitive. I remember saying that points will be just as
inaccurate as any other method, but would take less time to do and then
they'd have more time to get on with the job!
interesting, though, is that when you estimate with relativity using
points, and plan future iterations based on past velocity, it's
remarkable how predictable you can be. Even with very little
information at the point of estimating.
If you're interested in
this topic, you can read more from me here: agile