
Ask HN: Story Points or Time Estimates - jbrun
I run a start-up and I am not a software developer. We use agile development and 30 hour weekly iterations.<p>It has become very clear over the past 1.5 years that the software developer estimates are very inaccurate. This is based on a number of things, but it has not improved over time  - if anything estimates have gotten worse.<p>We are discussing the possibility of moving to Story Points instead of time estimates. What is your opinion on the two methods? Who uses what and why?<p>JB
======
DanielBMarkham
Ok -- I teach this, so I should know the answer.

The purpose of story points is to separate estimation into three pieces:
relative complexity, work, and duration. Story points are unit-less -- they
mean nothing in terms of hours. Unless you understand that, you'll end up
doing some kind of points-to-hours computation which misses the entire purpose
of having story points to begin with.

I've found for some reason that developers have a difficult time doing
duration estimates, which is really what you're looking for as a PM. Using
story points effectively is a great way to get a team back on track -- but you
need to know what you're doing. There are lots of ways to mess up.

------
fugue88
To use story points, you would have a linear model of some sort so that you
could calculate how long, on average, a story point would take to complete.

If you know how to do that (the model), you could apply the exact same
technique to the "estimated time" numbers to get a more realistic "expected
time."

Changing from time to points won't improve the developer estimates at all;
instead, it will further obfuscate them and reduce accountability, in my
opinion.

~~~
jbrun
Thanks, that is my inclination as well.

~~~
jamesbritt
DanielBMarkham is correct.

The goal is to first get a feel for estimating tasks relative to each other.

Then, over time, see how many story points you complete in a given time, and
eventually use that to make a correlation between points and hours.

The advantage of not going straight to time estimates is that you avoid the
tendency to think you can get more done in a given time that is realistic.

