Story Points Revisited

I like to say that I may have invented story points, and if I did, I’m sorry now. Let’s explore my current thinking on story points. At least one of us is interested in what I think.

Stories, of course, are an XP idea, not a Scrum idea. Somehow, Scrum practitioners have adopted the idea. Even though the official Scrum Guide refers to backlog items, having backlog items be User Stories is a common Scrum practice.

At least to the limited extent that they get it right. I’ve written elsewhere about the general use of stories as she should be done. Here we’ll talk about “Story Points”.

In XP, stories were originally estimated in time: the time it would take to implement the story. We quickly went to what we called “Ideal Days”, which was informally described as how long it would take a pair to do it if the bastards would just leave you alone. We multiplied Ideal Days by a “load factor” to convert to actual implementation time. Load factor tended to be about three: three real days to get an Ideal Day’s work done.

We spoke of our estimates in days, usually leaving “ideal” out. The result was that our stakeholders were often confused by how it could keep taking three days to get a day’s work done, or, looking at the other side of the coin, why we couldn’t do 50 “days” of work in three weeks.

So, as I recall it, we started calling our “ideal days” just “points”. So a story would be estimated at three points, which meant it would take about nine days to complete. And we really only used the points to decide how much work to take into an iteration anyway, so if we said it was about 20 points, no one really objected.

I may have made the name-changing suggestion. If I did, I’m sorry now. Here are some of my current thoughts on the topic, from an email to my colleague Simon, who asked:

Do you really regret they were invented, or do you simply deplore their misuse when relative sizing is not properly understood?

I replied that

I certainly deplore their misuse;

I think using them to predict “when we’ll be done” is at best a weak idea;

I think tracking how actuals compare with estimates is at best wasteful;

I think comparing teams on quality of estimates or velocity is harmful.

Let’s look a bit more deeply.

Some approaches to “Agile” actually recommend normalizing story points across teams, in the name of easier planning. While this seems sensible enough on the surface, it’s too easy to fall into the trap of comparing teams, and, too often, organizations do that.

Comparing

First of all, even if they “look the same”, each team has its own skills and works in its own environment. So if they look at two stories that seem the same, and one team says it’s a two and the other one says it’s a six, that’s just not very interesting, and it’s certainly not a useful way to compare teams.

Now, you and I, seeing that situation, would approach it with curiosity, first whether the situations were similar enough to compare, and then to explore whether the team with the higher estimate needed some kind of help that we could provide. That would be good. Implicitly or explicitly concluding that the “slower” team was inferior or messing up in some way – that would be very bad, but it is unfortunately common.

I think given two teams producing things, it’s an irresistible temptation, for many managers, to compare them. I think it’s irresistible enough that I’d drop the notion of story points, and even the notion of estimating stories at all, where possible. We’ll come back to the question of how to work with fewer estimates, and there are other articles here addressing that as well.

Tracking

To many managers, the existence of an estimate implies the existence of an “actual”, and means that you should compare estimates to actuals, and make sure that estimates and actuals match up. When they don’t, that means people should learn to estimate better.

To me, the important thing in Real Agile is to pick the next few things to do, and do them promptly. The key question is to find the most valuable things to do, and to do them quickly. Doing them quickly comes down to doing small slices of high value, and iterating rapidly. Story cost estimation doesn’t help much with that, if at all.

So if the existence of an estimate causes management to take their eye off the ball of value and instead focus on improving estimates, it takes attention from the central purpose, which is to deliver real value quickly.

This makes me think that estimation, be it in points or time, is to be avoided.

Pressure

Related to the estimate / actuals concern is the natural pressure of management to want “more”. However much the team is getting done, it’s not enough. More, more, more.

The best way to deliver value isn’t more, more, more, it’s to do small valuable things frequently. If instead of estimating stories, we slice them down to “small enough”, we can come to a smooth flow of value, delivering all the time.

The focus on...