Many Agile teams use the terms Story points and Complexity points interchangeably. Agile teams believe that they are better than hours just because they are based on complexity and relative size. Mike Cohn suggested that it is wrong to use story points to depict the complexity of developing a feature, they are all about the effort.
Mike mentioned,
I mention this because I find too many teams who think that story points should be based on the complexity of the user story or feature rather than the effort to develop it. Such teams often re-label “story points” as “complexity points.” I guess that sounds better. More sophisticated, perhaps. But it’s wrong. Story points are not about the complexity of developing a feature; they are about the effort required to develop a feature.
Mike gave an interesting example where he compares the two backlog items of licking 1000 stamps and performing a simple brain surgery. According to Mike, despite their vast difference in complexity, they should still be given the same story points because they would take the same amount of time.
In a similar discussion on the Scrum Development group, Adam Sroka mentioned that in order to have a stable enough measure for velocity, teams need something which is close to time. Likewise, stories should correlate to relative effort and effort is comparable to time.
This however does not mean that teams should start estimating in hours. Estimating in hours has been found to be wasteful and inaccurate by many. Mark Levison commented,
Estimation is a waste. Estimation of tasks in hours is utter waste, people spend hours debating minutia, when they would better off just starting. Even estimation of stories in points is a waste, however to make your projects progress predictable and transparent this requires that stories be roughly the same size +/- one Delta. For most teams (mature or not) this turns out to be difficult, so they stick to story points.
Jeff Sutherland too, strongly supported story points as compared to estimation in hours. According to Jeff
Story points are therefore faster, better, and cheaper than hours and the highest performing teams completely abandon any hourly estimation as they view it as waste that just slows them down.
Mark Kilby commented to make sure that people new to Agile do not assume that Story points = effort = hours. According to Mark while making a decision on the story point, though effort is important, however enough consideration must also be placed on uncertainty. Mike agreed that there is no equivalence relationship between points and hours.
Perhaps the way to say that is that points are a function of effort, risk and uncertainty, or SP = f(E, R, U). (Call one of those complexity if you want; it’s not important.) The idea is that points are an estimate of the effort involved. Risk, uncertainty, complexity, doubt and other things people have mentioned here can be incorporated BUT only to the extent they affect the expected effort. If something is complex but that complexity will not affect the time to implement the feature, that complexity should not affect the estimate—that was my point with the lists of numbers to be multiplied or added.
Thus, story points should be based on effort and the effort should be able to take into consideration factors like risk, complexity, doubt etc. The key is to realize the question that story points help in answering. As Mike put it,
The goal of estimating is to answer questions such as “When will you be done?” or “How much functionality can we have by the given date?” If that is true, then whatever unit we estimate in and whatever approach we use will need to be about time.
