Why I don't use story points

I haven't thrown points since I left Pivotal. I'm not philosophically opposed to them, I just haven't actually been in a situation where I thought they were worth the cost of getting a team to use them, and to use them correctly. A lot of people have really strong negative reactions to points and pointing, and they usually don't feel like the highest leverage change I can make on a team.

Some Pivotal-specific Background

You can skip this if you worked at Pivotal, but Pivotal is the only place I've worked that did it this exact way, so I want to give folks who weren't there some extra context.

When I say "throw points" I'm talking about the specific way that Pivotal did pointing, and in particular the way Cloud Foundry teams in San Francisco did pointing, which of course I think is the Right Way to Do It.

You're in IPM, you have the whole team gathered around a Tracker story up on a big screen, and then everyone holds up their hands in a fist and someone (usually the anchor) counts off "one two three" and then you all at the same time show how many points you think the story is by holding up fingers – 1, 2, 3, 5, or if you're feeling very spicy, you bring the second hand up for 8. Then there's possibly ten seconds or so of discussion about the right way to throw a 3 and whether or not the 1 is the "first 1" or the "second 1" in the Fibonacci sequence, and then you actually discuss the points.

Then all the engineers haggle over what the point number actually is. Everyone has to agree before the points get recorded in Tracker. Usually the people who threw very high or very low numbers speak first and explain why they think it's particularly easy or particularly hard. Sometimes the person with the high outlier explains why there's something the rest of the team wasn't thinking about that makes it harder. Sometimes the person with the low outlier knows something that the rest of the team doesn't that makes it easier. Sometimes we find out that one person on the team did something exactly like this recently, and so it's going to be much easier if they work on it than if anyone else does it.

When I have seen points used outside of Pivotal they weren't "thrown," a manager just asked "how many points is this?" or asked the engineer working on that task to put an estimate on it.

The Case for Points

You get two things if you use points this way: A conversation, and values that you can use to generate reasonably good medium-to-long term estimates.

Within Pivotal circles the conversation about points tends to focus on the benefits of the conversation. Mostly the value here is "something that only one person knows get surfaced to the entire team." This is also sometimes the point where the team realizes that there's a 20% slice of the work that delivers 80% of the value.

The other thing you get is "pretty good estimates." Once you have a few months of data about how many pointed stories the team completes in a week, you can use that average points per week to extrapolate out about how many stories the team will complete in the next few weeks or months. These estimates, being estimates, aren't perfect, but they're really useful for having conversations like, "Is there anything that's above [important story] that we can move down below it so we can deliver [important story] by [important date]?"

Points are a way to get engineers to make time estimates

Here's a controversial opinion that I was converted to in the course of conversations for this piece: Points are just time. They're a way to get time estimates out of a project while (hopefully?) avoiding some of the social problems with time estimates.

Engineers both generally dislike giving time estimates and are bad at making time estimates. They tend to make time estimates by looking at the entire problem and then guessing how long it's going to take, but as I've written about before, estimates aren't guesses. Estimates need to be based on some kind of calculation or model to be useful

If points are so great, why don't I use them?

Every team I have ever seen use points effectively has also spent at least a few minutes in every meeting discussing, "What exactly is a point, really?" Some back of the napkin math suggests that Pivotal spent about $1 million dollars a year considering this question. I find this conversation tedious.

They only help you estimate once you have data, so they're not useful on engagements shorter than 3 months. I'm rarely on long engagements these days so I'm not getting much value in exchange for teaching how to actually point and then enduring the "what is a point, really?" conversation.

Anyone I know who has looked carefully at the estimates says that points are no better and if anything slightly worse at estimates than just counting stories.

When would I use points?

I think they're really useful in one of two situations.

• You are working a project that will take at least 6 months, you expect both team composition and the project's goal to be relatively stable over that period, and there's some reason that granular estimates are important enough to train everyone to make and use estimates correctly. You can't just deal with the problems that estimates handle by doing the most important thing first and the second most important thing second and so on.
• You are working for an organization where every team uses points in approximately the same way, and people move between teams on a regular basis, so training someone to make and use estimates correctly on one team will pay off for their entire career at the organization.

I'll be somewhat surprised if I find myself working in the second sort of situation again!

The first situation I expect to get into at some point but it's rarer than you might think. Many projects are shorter than that, or change direction or team composition more often than that, or report to executives who aren't actually that sophisticated about software estimates.

I've worked on projects in the past few years that had intense deadline pressure – like, "this gets done or the company doesn't survive" type of stuff. I didn't use points in those situations because I had other tools that were more effective and easier to teach. We broke the work down into very small pieces. We organized it so that the company-threatening stuff shipped long before the deadline and then followed it up with "now make it less annoying" work.

On my current project, StoryTime, we don't throw points because there's basically just one engineer, and we've been getting good enough predictions from raw story counting. We're changing the backlog pretty regularly based on customer feedback so we just don't need multi-week or multi-month predictions.

When should you definitely not use points?

If you're not having a conversation when you assign points to stories, you shouldn't be using points. Managers shouldn't assign points to stories. Product Managers shouldn't assign points to stories. I could maybe see an individual engineer using points as part of the process of creating an estimate for a larger piece of work but in general I don't think that engineers should be estimating individually either.

If people on the team are trying to "hold engineers accountable" for their estimates, you should also stop using points. There are lots of ways to make choices about work sequencing without estimates and if management is abusing estimates you should ideally stop using them and switch to another method of prioritization. (I know, easier said than done, but there are a lot of ways to quietly avoid giving estimates especially if the organization isn't especially sophisticated about them.)