The Case for Story Point Estimates

I have been a fan of story points ever since I attended a seminar several years ago where Mike Cohn presented the concept. I never really trusted other estimating practices such as function points and time-based estimates. Why? Software development projects are rarely similar from project to project, yet these practices focused entirely on past experience. Therefore, to get a "reliable" estimate of time for every new project you needed to gain a lot of experience. In other words, you have to figure out up-front how you will do the work. Not only does this take a lot of investment up front, it also does not account that the work you do later could change based on the work you do now. The estimates assume that nothing will change in the effort of doing the work, which is definitely not true in the Agile world. What I like about Story points is the focus is on the relative size of "things", then how they will be accomplished. As Mike would say, "Estimate size now, derive duration later".

Even though I am sold on story points, I have had much difficulty selling the concept and value to others. I'm having an easier time with the development team, but really struggling with stakeholders/product owners. These groups always want to know when things will get done as soon as possible. Story points in itself don't give you the answer, however they help determine velocity of the team which eventually will help you better predict what could be part of a release. For various reasons, it is too much of a paradigm shift for some to accept an estimate that isn't time based, yet they have much comfort of the team throws out some arbitrary number early on a release without much knowledge of how events are going to unfold.

It looks like I'm not the only one dealing with this struggle. Tobias Meyer, on his blog Agile Thoughts, addresses some of the arguments others have had about using Story Points as estimates. Following are the arguments, read more on his post "Estimation: Time or Size" on how he address each arguments. Good stuff!

Argument 1: Estimating in hours allows a developer to measure his estimate against his actual, and use that data to improve his estimates in future.

Argument 2: Our customers/product owners don’t understand story points; they need to know how many hours developers are working so they know how much the work will cost.

Argument 3: Story Points will map to time anyway, very soon we’ll see that (e.g.) one story point is worth 2.5 hours, so it is better to skip the intermediate step and just measure in hours.

Argument 4: Story Points don’t allow you to improve your estimation techniques.