In the agile process, when we speak of estimating, we refer to Points (often called Story Points).  This article explains Points and how we use them in the estimating process.

First, let’s take a peek into a typical Project Manager (PM) – Developer conversation (maybe you’ve had a conversation like this yourself):

PM:  So, how long do you think it will take to finish this project?

Developer:  Oh, I don’t know, 2-3 weeks, maybe 4.

PM:  Well, how about this User Story; how long will that take?

Developer:  I’m not sure, but I would guess I can get that done in a couple of days, maybe three, or four.

Some things to note about this conversation:  In the first estimate, the Developer gives a range of 100% (2 weeks) to 150% (3 weeks) and then extends it to 200%.  What do you think the PM heard?  Let’s be kind, maybe he heard six weeks, which extends it to 300%.   A similar thing happens with the second estimate, but it’s smaller in scope so this time the range is from 100% (3 days) to 133% (4 days) to 167% when the PM adds a one day buffer to that estimate as well.

Clearly, there is something wrong with the estimating abilities shown in this scenario.  Note that this is not necessarily a reflection of the estimator’s inability to estimate well, but rather of the situation.

What’s wrong is that no one trusts the estimates because they are invariably wrong.

What if your estimates could be reliable and useful?  What factors would we consider?

First, there is the size of the problem in a perfect world; this is typically where the “2-3 weeks” estimate comes from.  Second, there’s the “unless something goes wrong”, which caused the developer to say, “…maybe 4.”  What goes into the “unless something goes wrong” check?  It is a consideration of risk and complexity and prior knowledge.  Let me explain, if the User Story under consideration has a high degree of risk, or is quite complex to implement, or if the developer doesn’t yet know how to use the technology that this User Story asks for, then the estimate goes up and becomes more approximate.  Finally, there’s the elapsed time: a simple table change may take the developer 20 minutes to design and document, but then it takes a 4-8 hour turnaround for the DBA to make that change in the Development database, so clearly this will increase the estimate too.  The same is true for testing:  Sometimes a simple enough fix causes all sorts of retesting.

So, instead of measuring estimates in hours, we need to measure estimates that consider:  size,  risk, complexity, prior knowledge and other factors such as elapsed time and testing impact.  For the lack of anything better to call it, let’s pick an arbitrary measure for this estimate and call it a Point.

Now, we can look at one of the stories we need to do, and say, arbitrarily, “This User Story is worth 1 point.”  Now, let’s estimate the other stories based on that first User Story.  Perhaps the second User Story is not as well defined and will require some developer research, it is also more complicated, so let’s say that User Story is worth, 5 points?

If we do this with just any numbers, then we run into a special kind of madness where we are splitting hairs over the difference between a 12 point apple and a 13 point orange.  Not only are the problems dissimilar, but since the 1 point item was arbitrarily chosen, the difference between a 12 and a 13 is quite nebulous.  For this reason, most agile teams use only specific numbers when estimating points.  These are typically:  0, 1, 2, 3, 5, 8, 13, and 20.  (This sequence is based on the Fibonacci sequence.)  Note that these are also integers, so there is nothing like 0.5 Points; the User Story is either 0 Points or 1 Point in size.

A lot of people don’t like the completely arbitrary selection of the value of a Point.  If instead, we say that a 1 Point User Story is roughly what one developer can accomplish in a standard day with no risk and easy complexity, then we have a basis for comparing the other numbers, a 2 is either twice as big, twice as hard, or twice as risky.  A 3 is probably some combination of these that make it likely to be 3 times bigger than a 1, and so on.

Further, a 0 is any User Story that’s a “gimme”.  If the developer says, “Oh, that’s no problem, I can have that fixed in 5 minutes,” that’s a 0 Point User Story.  Note, that ten 0 Point stories do not add up to 0 Points as ten little stories can easily take a day to accomplish.

Finally, there is 20.  Essentially, any User Story that is big enough to make you want to give it a 20, is too big to be estimated well, so a 20 is more of a red flag than a  legitimate points value, but this value allows you to estimate all of your stories, regardless of their size.

(Some teams include the integers 50 and 100 in their estimating.  This makes 20 just a big story, 50 is a story big enough to fill a sprint and 100 is the red flag that the story is too big to estimate.  I prefer to max out at 20 points.

In Summary:

Points are an estimate of size, risk, complexity and other factors such as prior knowledge, elapsed time, and testing considerations.

Points are typically an integer in the sequence:  0, 1, 2, 3, 5, 8, 13, and 20.

Points allow us to estimate the relative size of each story.