Traditional estimates attempt to answer the question, “how long will it take to develop X?” I could ask you a similar question, “How long does it take to get the nearest train station?
The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn’t depend on the person solving it, just as the distance to the train station does not depend on whether the traveler walks, runs, rides or drives to the station.
A story point is to program code what a kilogram is to sand or a kilometer is to distance: An arbitrary unit of measure which describes how heavy, far, big or complex something is.
So if we want to answer how long will it take to develop a particular software, we add up the story points, divide by the velocity, and that gives us the time. Think of moving sand: 100 kg / 10 kg per hour = 10 hours. 100 SP / 10 SP per Sprint = 10 Sprints. But how big is a story point? And how do I know what the velocity is?
If we’re measuring sand, it’s easy to define a reference kilogram. With program code, it’s more difficult. Once I played with the idea of converting lines of code into grams, 1000 lines of code = 16 A4 pages = 100g of good paper, but that’s just silly, isn’t it?
So how do we come up with our reference story point? And how do we know what velocity is?
Under Scrum, estimates are done by the team (if possible, the whole team) who will actually perform the work. So the team defines what a story point is. The classical approach is to look at list of backlog entries, take what appears to be the easiest, and declare that is a 2. Everything else is estimated relative to that task.
The thing to realize about about estimates is that they are very imprecise. +/- 50%. One technique for dealing with a cost ceiling is to define an estimate such that the actual effort needed will be <= the estimate in 90% of the cases, regardless of whether they are measured in days, hours or point.
So Story Points are usually estimated on the Cohn Scale (named for Mike Cohn, who popularized the concept): 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. Why is there no 4? Well a 3 is a 3 +/- 50%, so a three actually extends from 2 to 5, a 5 from 3 to 8, etc. The difference between 3 and 4 is nowhere near as significant and between 1 and 2, so we don’t give estimates that give us a false sense of precision.
Summed together, many imprecise estimates give a total that is a remarkably accurate estimate of the work to be performed (the errors tend to cancel each other out, rather than accumulate). For this to work, the backlog entries must be independent of each other. If you estimate tasks that are dependent on each other, then errors accumulate and cascade. (See the update of 27/05/11 below).
Where does velocity come from? Before the first sprint, we guess. In the first sprint, the team accepts work based on gut feeling and discussion. After each Sprint, we measure the velocity. After two or three Sprints, the average measured velocity can be used to predict the velocity in the future, and thereby the completion date. It is also possible to derive values, like $/SP, which can be used to estimate project costs.
Story points are used to estimate items on the product backlog, i.e. items which represent value to the customer. They are not used to estimate effort to produce artificats needed by the team. In Scrum, we track progress based on results delivered, not on effort applied. So use story points to estimate stories in the Product Backlog, not tasks in the Sprint Backlog.
Used this way, the Scrum Release Burn Down Chart provides an accurate picture of the progress of the project, so management can rapidly recognize and react to the project’s progress (or lack thereof).
[Update 31/10/2010: Thanks to Christopher Messina for pointing out some ambiguities in the concluding paragraph, which I have now corrected.]
Update 27/05/2011: I have realized that two kinds of independence are critical for accurate estimates. Check out this new blog entry – The Key to Good Estimates
Update 03/12/2017: I have been using a more concrete basis for estimating stories than story points: – A concrete alternative to estimating story points in Scrum