Story Points… Why?

I am continuously amazed at the dysfunction I find around Story Points. Really all estimation to be honest. But specifically Story Points.

Before I get directly into my thoughts. Let’s take a look at what the creator, Ron Jeffries, of Points has to say about it:

From Ron’s article: https://ronjeffries.com/articles/019-01ff/story-points/Index.html

Think of this scenario.

A team estimates in Story Points.
Story Points are used in a comparative estimation to Stories completed in the last iteration.
The team is predictably hitting 30 points per iteration.

If you are forced to estimate, whether it be with Story Points or some other method, then using comparative estimation from the most recent iteration makes sense to me.

Now what happens when this team drops to 10 points per iteration over say the last 3 iterations. Does the point value really matter? What value does the estimation provide the team or anyone else on determining the cause of the slow down? To me it doesn’t provide any value at all, and we could get the same information simply by counting “right-sized” Stories.

“Right-sized” to me is getting Stories narrowed down enough that they still have value and have a single acceptance test. Ron mention’s this in that same article. And this takes practice to get to, and people struggle with this quite often, but it really eliminates all of this need for estimation.

Right-sized Stories typically take no more than a day to implement, and in most cases can be done in a couple of hours. So if they are that size, why bother estimating, just do it and move on to the next Story.

Continuing with the team example from above. Let’s assume that it is very difficult to get Stories small enough to a few hours or even a single day. If this team is narrowing their stories, so they could be completed within 2-3 days, then on average, they are estimating 10 Stories every iteration somewhere between 1-3 Story Points. Does it really matter if they look at numbers that show the team has slowed from 30 Story Points to 10 Story Points vs 10 Stories to 3 Stories? Does the estimation in points really help you identify the cause of the slow down in delivery? Or is it that since its a larger number it eases the pain a bit for the charts and graphs folks?

The answer to me is no. It doesn’t really help you identify or address any of the reasons for the slow down. What does it help with? Most often it helps management to provide some really dysfunctional practices. Comparing teams against one another to “drive better estimates”, using estimates as a means to track a delivery date, and one of my favorite topics of dysfunction, the “more-faster” mentality.

Furthermore, what happens when you estimate a Story at 5 points, and on average the team completes a 5 point Story every 7 days, but this one took 3 days or 9 days or oh no, what if it carried to the next iteration? What happens is a big pain in the ass conversation of “why we were wrong about our estimate.” Because “This team needs to be better at estimates.”

This does not attack the root cause of why the sudden decrease in working software being delivered. Which could be many. Maybe people moved on or maybe the work is currently much more complex than anything we have tackled before.

We aren’t building trinkets on an assembly line. This is knowledge work and shit happens. With that said, I go back to creating narrowed Stories. You can do this with Story Maps extremely effectively. Ask Jeff Patton, he will tell you, show you examples, and teach you how to do it. You could refer to an awesome article posted by Bill Wake on what User Stories are as well. https://xp123.com/articles/what-is-a-user-story/. Or you could start narrowing your Stories to a single acceptance test and watch the magic happen of how fast you get through that.

So if you can narrow Stories to consistently be delivered within 2-3 days at the most, why bother estimating that. Just count them and you could provide a forecast for when things could be done when the scenario calls for it.

I think my position right now is clear on this, but as always I am open to being proven wrong and being shown the light on valuable estimation. Even if that is with Story Points. And ultimately, if the team you work with finds estimating to be of benefit, then by all means, have fun, live and be well! But, I have yet to experience a single scenario where the estimate a team provides wasn’t used for anything but pressure, tracking, team comparison, and pain to those teams that provided the estimate.

Here are some talks on #NoEstimates.