Story Points Estimate Effort Not Just Complexity

A client asked me, "When will my team be done with this project?" This is probably the bazillionth time I've been asked that agile project management question in one way or another.

I have never once been asked, "How hard will my team have to think to develop this project?"

Clients, bosses, customers and stakeholders care about how long a project will take. They don't care about how hard we have to think to deliver the project, except to the extent that the need to think hard implies schedule or cost risk.

Teams Think Story Points Are Just Complexity

I mention this because I find too many teams who think that story points should be based on the complexity of the user story or feature rather than the effort to develop it.

Such teams often re-label "story points" as "complexity points." I guess that sounds better. More sophisticated, perhaps.

But it's wrong.

Complexity is a factor in the number of points a product backlog item should be given. But it is not the only factor. The amount of work to be done is a factor. So, too, are risk and uncertainty.

Taken together these represent the effort involved to develop the product backlog item.

An Example of Why Points Can’t Be Just Complexity

In a Scrum Master course a few years back, I was given a wonderful example of why story points cannot be just complexity. Let me share it with you now.

Suppose a team consists of a little kid and a brain surgeon. Their product backlog includes two items: lick 1,000 stamps and perform a simple brain surgery -- snip and done.

These items are chosen to presumably take the same amount of time. If you disagree, simply adjust the number of stamps in the example.

Despite their vastly different complexities, the two items should be given the same number of story points because each is expected to take the same amount of time. In this carefully chosen example, the volume of work (licking 1,000 stamps and one snip to some part of the brain) and the complexity of that work combine such that each will take the same amount of time.

So complexity is a factor in the number of story points assigned, but only to the extent to which that complexity increases the expected effort.

Adding Risk and Uncertainty

Remember I said it was a simple brain surgery. (I’m not even sure that exists, but go with me for another minute.)

If there was a risk the surgeon began the surgery and discovered he also needed to do some extra work during the surgery, that would be factored in and the estimate increased. So if we know a surgery will be simple we might call it 5 points. But if there’s a risk the surgery uncovers other work to be done, we would increase the estimate to a higher value.

The Right Person for the Job Should Do The Job

Our example of the surgeon and the little kid points points out another aspect of agile estimating. We should assume that the right person for the job will do the work.

We do not assume the little kid will finish school, go to med school, do a seven-year residency and only then begin the brain surgery while we have a skilled surgeon sitting in a cubicle licking stamps.

Of course reality intrudes and occasionally the "wrong" person for a job does the job, but that will rarely be as dramatic as in this example.

Story Points Are Effort

So, story points are an estimate of the effort involved in doing something. That estimate should be based on a number of factors, including the volume of work, the risk or uncertainty inherent in the work, and the complexity of the work.

But story points are not solely about complexity.