Ask HN: Story Points or Time Estimates
I run a start-up and I am not a software developer. We use agile development and 30 hour weekly iterations.
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.
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?
JB
4 comments
[ 3.7 ms ] story [ 26.9 ms ] threadIf 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.
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.
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.