Story Points and Hours
A while back, Mike Cohn posted a concise explanation of how story points relate to hours. It’s a common phenomenon; folks who are used to traditional project management really want those points to equate directly into, “how long will this take?” The important thing to remember is that story points are a measure of capacity and effort, not time. The next thing to remember, and this really messes with teams new to agile methodologies, is that story points are mostly meaningless until you have accumulated historical data. Without some data on trends, a story point really is a guess; what does 1 point mean versus 8 points when this is your very first iteration? You have to go on gut feelings, and there will be resistance to that kind of “guesstimation”—which is pretty sad when you realize that guessing hours is not much better than guessing points.
At least with the points, you’re admitting that it’s an estimate. Hours tend to lull people into a false sense of security, assuring them that this is the timetable, and if you deviate from the established time line, then it’s the implementers’ faults, not the estimators’. Which brings me to another important part: story points are estimated by the team, not by a single project manager dictating from on high. This puts the onus on the team to estimate better with each sprint (which they will, given the freedom to do so), instead of being forced into a death march to meet arbitrary time limits.
Estimating story points is an ongoing learning experience. You start with none and build from there; once you’ve had three or four iterations under your belt, you’ll notice the team getting more accurate. All one point stories will start to look similar and take similar amounts of time, and once you have that in your arsenal, estimating with the story points both generates a realistic timeline and gives your team some breathing room.