Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?"

A good question, and in all honesty, developers can be an even more critical audience than managers.

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 how I get there.

A story point is to program code what a kilogram is to sand or a kilometer is to distance: An arbitrary unit of measure.

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. 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 say 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 tasks, 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).

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 should represent value delivered to the customer, not simply worked performed. Used this way, the Scrum 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).

Story Points are not totally uncontroversial, and I'll talk about some of the issues and alternatives to Story Points in a later post.