Story points are about time. There, I’ve said it, and can’t be more clear than that. I’ve written previously about why story points are about effort, not complexity. But I want to revisit that topic here.

The primary reason for estimating product backlog items is so that predictions can be made about how much functionality can be delivered by what date. If we want to estimate what can be delivered by when, we’re talking about time. We need to estimate time. More specifically, we need to estimate effort, which is essentially the person-days (or hours) required to do something.

Estimating something other than effort may be helpful, but we can’t use it to answer questions about when a project can be delivered. For example, suppose a team were to estimate for each product backlog item how many people would be involved in delivering that item.

One item might involve only a programmer and a tester, so it is given a “two.” Another item might involve two programmers, a designer, a database engineer, and a tester. So it is given an estimate of “five.”

It is entirely possible that the product backlog item involving only two people will take significantly longer than the one involving five people. This would be the case if the two people were involved intensely for days while the five were only involved for a few hours.

We may say that the number of people involved in delivering a product backlog item is a proxy for how long the feature will take to develop. In fact, I’d suspect that if we looked at a large number of product backlog items, we would see that those involving more people do, on average, take longer than those involving fewer people.

However, I’m equally sure we’d see lots of counter-examples, like that of the five and two people above. This means that the number of people involved is not a very good proxy for the effort involved in delivering the feature.

This is the problem with equating story points with complexity. Complexity is a factor in how long a product backlog item will take to develop. But complexity is not the only factor, and it is not sufficiently explanatory that we can get by with estimating just the complexity of each product backlog item.

Instead, story points should be an estimate of how long it will take to develop a user story. Story points represent time. This has to be so because time is what our bosses, clients and customers care about. They only care about complexity to the extent it influences the amount of time something will take.

So story points represent the effort involved to deliver a product backlog item. An estimate of the effort involved can be influenced by risk, uncertainty, and complexity.

Let’s look at an example:

Suppose you and I are to walk to a building. We agree that it will take one walking point to get there. That doesn’t mean one minute, one mile or even one kilometer. We just call it one walking point. We could have called it 2, 5, 10 or a million, but let’s call it 1.

What’s nice about calling this one walking point is that you and I can agree on that estimate, even though you are going to walk there while I hobble over there on crutches. Clearly you can get there much faster than I can; yet using walking points, we can agree to call it one point.

Next, we point to another building and agree that walking to it will take two points. That is, we both think it will take us twice as long to get to.

Let’s add a third building. This building is physically the same distance as the two-point building. So we are tempted to call it a two. However, separating us from that building is a narrow walkway across a deep chasm filled with boiling lava. The walkway is just wide enough that we can traverse it if we’re extremely careful. But, one misstep, and we fall into the lava.

Even though this third building is the same physical distance as the building we previously estimated as two walking points, I want to put a higher estimate on this building because of the extra complexity in walking to it.

As long as I’m cautious, there’s no real risk of falling into the lava, but I assure you I am going to walk more slowly and deliberately across that walkway. So slow, in fact, that I’m going to estimate that building as four walking points away.

Make sense? The extra complexity has influenced my estimate.

Complexity influences an estimate, but only to the extent the extra complexity affects the effort involved in doing the work. Walking to the one-point building while singing “Gangnam Style” is probably more complex that walking there without singing. But the extra complexity of singing won’t affect the amount of time it takes me to walk there, so my estimate in this case would remain one.

Risk and uncertainty affect estimates similarly. Suppose a fourth building is also physically the same distance as the building we called a two. But in walking to that building we must cross some train tracks. And the train crosses at completely unpredictable times.

There is extra uncertainty in walking to that building—sometimes we get there in two points. Other times we get stuck waiting for the train to pass and it takes longer. On average, we might decide to estimate this building as a three.

So, story points are about time—the effort involved in doing something. Because our bosses, clients and customers want to know when something will be done, we need to estimate with something based on effort. Risk, uncertainty and complexity are factors that may influence the effort involved.