Why I Use Points For Estimating

A recent discussion among some colleagues of mine centered around the use of points (or story points) for estimating and the utility of points. The basic concept behind points is one uses a dimensionless quantity to size chunks of work relative to some standard everyone can agree upon. The classic example comes from Mike Cohn’s book, Agile Estimating & Planning, where he discusses how to rate dog sizes from 1 to 10 along a continuum of dog breeds: chihuahua, daushound, terrier, poodle, Great Dane and Saint Bernard. Usually, the breeds shake out to something like this:

You have the largest and smallest dogs at the extremes and then the other breeds fill the rest of the continuum based on their size; there could be gaps, that’s OK.  More-or-less this is what happens when you estimate software features using points; some features are “really small” and others are “really big”. In the case of software, “really big” normally means there is so much uncertainty in the feature the developers can not give an accurate estimate on the cost.  As for all the ones in the middle, depending on when the feature is scheduled to be implemented, I normally chunk the feature into multiple pieces (2 or 3) that can fit into an iteration.

Invariably, when people first start out with points, they get confused and give me the collective “Huh?  What’s a point?” or more likely “What’s the point?”.  They are so used to estimating in hours\days\weeks they cannot understand why we might use points.  They understand that they are bad at estimating time, but they cannot think of another way to come up with an estimate.  When I am in this situation where people are confused, I use one of my “tricks”; I conflate the two concepts by saying, “One point is a(n ideal) day”.  Once I do this, the participants can do the points-to-time conversion in their head from and they are off to the real work of estimating features.

You might say, “Isn’t that a bit dodgy?”  Yes it is, but the real point (pardon the pun) of the exercise is to quickly come up with an estimate for the feature in the right order of magnitude.  It is not to commit to the project duration on, at best, uncertain information.  At this stage where the participants are having the “huh?”, we are talking about an initial estimate at the beginning of a project where the participants have little or no experience with XP\Scrum\Agile and little or no experience with their project.  They are not really going to estimate any differently than they have in the past, they are going to think in time.  But notice what I have done by saying “One point is a(n ideal) day”; I have subtly removed duration from the project estimate and moved to size.

IME, there is very little harm to the project, or the Team, to say “This project is estimated at 300 points and will be 300 person-days of work.” That is actually very useful at the early stages to muddle the concepts since we are deciding on resource allocation and can play with the velocity estimates to see when the Team might get done.  Later when the Team has been working in multiple two-week iterations, they are able to DERIVE the duration from their velocity and when they say, “We have 200 points left, our velocity is 25 and we predict we will be done in 8 iterations”, it is really clear what is going on.