(2019-05-23) Jeffries Story Points Revisited

Ron Jeffries: Story Points Revisited. 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.

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.

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.

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.

Because estimates are at least implicated in the application of undue pressure, I’d prefer to avoid them. I’ll go further: I’d prefer to avoid iteration or Sprint planning entirely. (Planning Game) We wouldn’t work to fill up a budget for the next few weeks: we’d work to have a list of the few most important next things to do.

The next question, of course, is “when will all this be done?” The answer is that no one knows

It’s far better to pick a close-in date for the next release to customers, and pick as much good stuff into that release as possible

I like story slicing, which is the practice of takng larger stories and slicing them down into smaller ones

there’s a trick. I mentioned it in Getting Small Stories and Slicing, Estimating, Trimming. I learned it from Neil Killick: slice stories down until they just need a single acceptance test.

First, think about one or a few important capabilities for the next release. Talk about what the problems are that they solve, and what software might help solve them. Talk about the simplest capabilities that might help a bit. We don’t have to solve everything: often if we can give a bit of help, that’s enough to get things rolling

slice off thin slices of the improtant capabilities and do them.

You’re trying to get into a frame of mind where you think “If we just did this one little thing, Customer Jack could actually use this”. Then, do that little thing and let Customer Jack try it. We want to move as quickly as we can to continuous delivery of value.

Well, if I did invent story points, I’m probably a little sorry now, but not very sorry. I do think that they are frequently misused and that we can avoid many pitfalls by not using story estimates at all. If they’re not providing great value to your team or company, I’d advise dropping them on the grounds that they are waste. If, on the other hand, you just love them, well, carry on!