# Stop using Story Points!

--

Why you should quit them and what to do instead.

People are notoriously bad at estimating how long something will take. What they are good at is comparing things and evaluating which one is the largest. It’s a primeval skill and it’s what the theory behind Story Points is based on.

When we were running around hunting bison, this skill came in handy when evaluating which animal was safe to attack and which one was just too strong. Put these same hunters in the modern age and in the back of the group, there would be a Project Shaman working on a perfect Excel sheet.

“Last moon we caught 18 Bison Points, so given the average velocity of the group, we can definitely take on that Wooly Mammoth, boys!” The team would commit to the new velocity and be crushed under furry paws.

Story Points were a great idea back when Extreme Programming hit the streets, but they have turned out to be an awful means of communication. Nobody gets it and everybody uses it to calculate. Instead of deciding if something is bigger, they are used for detail planning and clairvoyance.

Developers are unsure whether they should pick complexity or amount of work. Do we estimate in uncertainty or risk? Do we take a buffer? The rest of the team only cares about when it’s done and so begins the endless debate about lead time and cost of story points. Why is team A delivering more story points? Can we baseline the estimates cross team? How many man-days is a story points? Do we double when pair programming or cut it in half?

Let’s just drop that unproductive occupational therapy and move to more productive means. Here are three alternatives:

## No estimates.

Seriously, it’s a thing. It’s easy and it can work. If the added value of estimation is zero or worse, just stop doing that. You build what you can given the team and time. Progress is measured by customer satisfaction instead of spreadsheet colours.

## 1 story = 1 point.

Focus on writing good stories and this works as a charm. If you have 10 stories and 8 of them are done, it’s easy to track progress. This is especially good for medium to large projects and burn down reports are super easy to build. From there, you can even start projecting delivery dates.

## The estimate goat.

The goat knows and it is as good as putting the team together for 3 hours.

In the old days, projects were always 80% done. Today, the burn down chart stagnates indefinitely. People tend to overestimate the value of estimates. It’s a fetish of those who want to control what they don’t really understand. No project manager will ever be remembered for how spot-on her projections were.

Estimation is only a problem in large fixed-price death march scrum-but projects. Don’t try to fix that by expecting developers to predict the future. Focus that energy on coaching your end customer on how to deliver an agile project. The result and morale will be a lot better.

--

--

Freelance web developer, team leader and ideas guy. I help companies build better software and write about it at www.mikeveerman.be