The Genesis of Story Points by the Inventor of Story Points - Ron Jeffries
I have had many discussions and some arguments about story pointing and project estimating over the years. One day I got so frustrated with a colleague that I decided to go to the source. The cool thing is that I think I found the source!
Ron Jeffries is credited with being the inventor of story points. Ron is one of the original seventeen signatories of the Agile Manifesto and a co-founder of Extreme Programming (XP).
I think this video is fantastic and must-watch for anyone trying to figure out how to estimate Agile projects with any kind of accuracy
The Genesis of Story Points
I don't usually so this, but I also don't usually get authenticate message like this from the horse's mouth either. I have included main points of the transcript below.
I don't promise to tell the story the same way every time, but it's worth noting that on the first XP project we started with a large-scale estimate. As it happened, we had a complete set of stories for the whole product — it was a payroll system and we thought we knew everything that needed to be done. We spent just a few days estimating something like 400 stories, in terms of the number of weeks we thought each one would take — usually one, two, or three weeks.
We divided the team into two groups, estimated each half, traded cards, and reconciled. The product began with estimation. And a big skill in XP iterations was for the development team to look at all the available high-priority stories and choose as much as they thought they could get done that week.
What we started doing — and I don't remember exactly when — was associating stories with what we called ideal days. We would ask: how many ideal days would it take to code this? An ideal day was when they left you alone. No meetings, nobody was sick, the manager never showed up. Every programmer has that sense — every programmer wants to say "if you bastards would just leave me alone, I could do that in two days." They never do leave you alone, of course, but that was the concept.
So we used ideal days, and tracked how many ideal days worth of work we got done in each iteration. For a long time we were doing three-week iterations — how slow we were back then. It turns out it takes about two or three real days to get one ideal day's worth of work done, because of all the friction involved and some innate bias in your own estimation. So there was roughly a ratio of three between the days we estimated and the days it actually took. That was very confusing to management. We would say something would take three days and it would take seven, and they kept asking what was wrong with our estimation.
Our response to that was to start calling them points. Then it was easy — it takes about three days to do a point, so three points is going to take about nine days. It was the same math to the programmers. We just renamed it. Then we would have point values on the stories and say "we're doing about 30 points a week, but Jeff's on vacation and we've got that big meeting, so let's take 25."
The story point really started just to obfuscate the relationship between a made-up number — the ideal days — and the actual elapsed time. Someone along the way said you could call them gummy bears and it would work just as well. I think it was Joseph. Because the name genuinely does not matter.
Here is the problem, though. As soon as you make the relationship between points and time explicit — and that is what it was originally for — there will be a manager in the room who says "these 25 points should have taken you ten days and it took thirteen, what's wrong with your estimation?" And that question is completely irrelevant, because what you're really trying to do is choose how much work to take on. You get very good at that. You can do it without putting points on things at all. You can just look at the stories and say "I think we can do this much," and someone says "let's take one more," and nobody cares, because if you don't get it done this week you get it done next week. You're behaving adaptively as you go forward.
It's always silly to imagine that at the beginning of something you're going to know everything you'll know at the end. If a team is estimating perfectly and finishing exactly on the clock every single time, something is wrong. They're sandbagging. And if they're not sandbagging, they're certainly not working at the edge of their ability, because if you work at the edge of your ability, sometimes you fall off the edge. Statistically, that has to happen.
The ideal days were intended to be an internal measure — just something the team would use among themselves to figure out how many stories we were going to do. It was going to stay between us. But as soon as it bubbled up to a management level it became a measure, and then it became a target. And the only target that matters is the software. Don't mess with the software.
That is why I have looked favorably on the no-estimates movement, if it is a movement. Because the question of "what can we do this week" — which is where story points really came from — you don't actually need points for that. Just cut your stories down to roughly the same size, maybe about a day each, and count how many you're getting done. If you're getting about 20 stories a week and that drops to 17, you start asking what happened. You use the count as a trigger for a retrospective, for an inspection. But you don't treat it as a target, because the moment you do, any sensible team will meet that target by scaling their work to fit it. And that is not what you want.
Now, that opens the larger question: how did we know whether we could get the payroll done in the year we were given to do it? Honestly, I would mostly want to not answer that question, because I don't really know the answer. What I do know is this — there is no accurate way to predict the future. If there were, we would all be driving very expensive cars.
That said, if you want to tackle estimation seriously, there are two resources worth knowing about. If you want to do it the hard way, read Steve McConnell's books on estimation. He has documented every estimation technique you could possibly want, and they are as good as anything else out there. They won't be accurate — but nothing will be.
The other resource I would point you to is Software Estimation Without Guessing: Effective Planning in an Imperfect World by George Dinwiddie, published by The Pragmatic Programmers. It is a very interesting book because it approaches the problem from a different angle — looking at both the technical and the human sides of estimation, which is where so much of the real trouble actually lives. I would say read both and form your own view.
But for most projects, I would concern myself with flow rather than with estimates and actuals.
Ron Jeffries is one of the original seventeen signatories of the Agile Manifesto and a co-founder of Extreme Programming. He has written extensively about story points, estimation, and agile practices at ronjeffries.com.
George Dinwiddie is an agile consultant and coach and the author of Software Estimation Without Guessing: Effective Planning in an Imperfect World (Pragmatic Bookshelf). More of his writing can be found at blog.gdinwiddie.com.
