The Devil is in the Story Points

I recently had a chat with a developer who has a very negative perspective on Agile and Scrum. This isn’t surprising; many people do. One thing he said inspired me to write this blog post.

We were talking about Scrum, and I mentioned that I hate the word “sprint.” It implies that the team must run at full speed. The principles of the Manifesto for Agile Software Development state “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” Even Olympic marathon runners can’t sprint indefinitely. I’d prefer a term that doesn’t bring to mind people collapsing on the ground gasping for air at the finish line.

He said, and I’m paraphrasing here, that one of the reasons that Agile is popular is that it’s used to get developers to work more and to work harder. He’s not wrong. The use, and abuse, of story points is part of the issue.

Story points aren’t the cause. The cause is more complicated. Dave Thomas has given some excellent presentations on some of the reasons for the above, stating provocatively that “Agile is Dead.” I’ve also written about some of the misconceptions about how Agile is more efficient, if you are measuring time-to-specification. But the abuse of story points is one of the ways that things go wrong.

If you work on a Scrum team, you’ve probably heard or said things like this:

  • You guys did X story points last sprint, so I expect at least X points in the next sprint.
  • We only have X minus 2 story points allocated to the sprint so far, I’ll find a couple of small stories to squeeze in.
  • This team isn’t performing. They’re only completing Y story points per sprint!
  • I need to add this new story to the sprint. Sorry guys. What’s your story point estimate for it?

If you find the above statements familiar, (I know I am guilty of saying all of them at various times) I would hazard a bet that you also find yourself starting every sprint planning meeting by discussing the stories that were not completed last sprint. In other words, your team never finishes what you’ve asked them to commit to.

The problem with all of the above statements is that story points are an abstraction of complexity, effort, risk, understanding of the technology, code base and the story and numerous other things that may impact development. They are a way to evaluate “effort.” They are not a precise measurement of the time required to complete a story.

In short – you cannot plan a sprint, which is a fixed length of time, based on story points, which relate to time in a distribution (long winded but complete explanation here). If you are trying to maximize the story points or number of stories completed in each sprint you are setting yourself and your team up for failure every sprint.

Story points are useful for release planning, where you’re trying to get a rough idea of how much work there is and how many sprints it will take, and you’re frequently re-assessing this as more information becomes available. They’re also a good starting point for going into sprint planning.

However, once the team starts planning a sprint you have to let go of the story points. Many guesses and assumptions were made in the story point estimation. This is one of the benefits of agile estimation – we can move forward without knowing everything up front and then adjust or pivot as more information becomes available.

As the team starts to plan and then do the tasks, these guesses and assumptions are tested, and of course the “unknown-unknowns” start to appear. It’s up to the product owner to ensure that the team stays focused and delivers the most value each sprint, usually by adjusting the scope of the stories (not by changing or arguing about the initial estimate).

Coming back to the developer’s comment that inspired this post, story points have become the new planned versus actual hours, the very thing they were developed to escape. Here’s one example of how some organizations are trying to make story points into something they are not, and in the process undermining the benefits of using story points and sabotaging their teams’ agility.

I’ve also encountered organizations that compare the actual hours reported to the original story point estimates and use that in performance evaluations, starting conversations with “You take on average 5 hours per story point. We’d like to see you get it down to 3.” Ick. It’s not surprising that the developer feels he’s being forced into agile to make him work harder.

Delivering value to the organization, customer or user is what matters, not delivering stories or story points. Story points and velocity are useful tools for priotization and longer-term planning. It’s tempting as a product owner or manager to equate the number of stories or story points to value or to progress, but progress and value should be measured in KPI or another measurement of what return was recieved from the time invested.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s