Skip to main content

The Problem with Story Points

Dave Nicolette
Reading: The Problem with Story Points

Story Points

For starters, let me just say there’s no problem with story points.

Story points are a way of expressing the relative sizes of stories. They can be helpful for short-term planning of software development activities. Unfortunately, sometimes people get hung up on the numbers, and they lose track of the substance.

People can get into the habit of repeating the buzzwords and marketing phrases that go along with a particular named or branded Thing. I’ve noticed a lot of software development teams bring certain buzzwords into their everyday vocabulary and use them creatively (or carelessly).

It’s cool for a team to develop its own internal jargon. It helps make work more fun and may foster team identity and cohesion. But people sometimes lose track of the intended meaning or the value behind a term. In some cases, this can lead them to focus on things that aren’t important or helpful. “Story point” is a term that is subject to that pattern.

The Nounification of Verbs, and Vice Versa

It seems we’re always in a hurry, and we’re interested in ways to abbreviate or summarize so that our converations will be as brief as possible. After all, we have a lot of dependencies to wait for, and we’re keen to get busy waiting for them. No time for chit-chat.

Sometimes we get a bit carried away. The result can be puzzling, and even amusing.

To ask is a verb. The ask is not a Thing.

To spend is a verb. The spend is not a Thing.

Solution is a noun. To solution is not a Thing.

Leverage is a noun. To leverage, as a verb, started to appear in English dictionaries fairly recently, as these things go. The noun leverage was verbified as a shorthand way to say to apply leverage.

When you hear something like, “We’ll leverage the spend to solution the ask,” remain calm. Back away slowly. Make no sudden moves. Keep nodding and smiling. Remember your Happy Place.

Point, as in “story point,” is a noun. To point is a verb, of course. It means to indicate an object or direction by extending a finger toward the object or in the direction of interest. If you’re a dog, you can point with your nose instead of the finger that you don’t have. It’s considered good form to lift one of your front paws and stand very still.

How I Learned That I Don’t Know Agile

After years of working with various agile methods in various contexts, I thought I had a pretty good handle on the whole thing. And yet, the first time someone said to me, “We’re pointing today,” my response was:

“Pointing at what?”

“Not pointing at, silly goose! Our team is grooming today. We’re pointing our stories.”

“I see. Pointing them at what?”

“Are you kidding? I thought you knew Agile.”

“So did I. Now I’m not so sure.”

“You must be kidding! We’re assigning story points to our stories.”

“Oh, that. You’re sizing the stories.”

“What? No, we’re pointing them.”

And they did. And they were happy. All the stories ended up with numbers associated with them. And the ScrumMaster smiled upon the team, and the backlog was dapper, and the ALM spilled forth its gifts unto the Ready column, and the Sprint was packed, and the Product Owner did grin, and behold! snacks were upon the team, and a joyous noise rose up to the heavens.

A Thing to Do

As time went on, it became clear that there was no connection between the points and the team’s delivery capacity, value generation, sustainable pace, or quality. The points were never mentioned during sprint reviews or heartbeat retrospectives. They were just numbers.

“Sizing” might have had a purpose; a function; some sort of value. “Pointing” was nothing more than an activity that had been dictated to the team; an event to be checked off on the Sprint schedule. It was “a thing to do, like feeding Vaal“.

Well, Okay, What, Then?

Here’s what happens on proficient teams (at least, this is what I’ve seen happen):

  • 1. Someone reads the title of a story card aloud.
  • 2. Simultaneously, without analysis, without discussion, and without delay, everyone throws out a number from the set [1, 2, 3, 5, 8, 13]. They might use physical cards, a phone app, or their fingers. The range of values doesn’t exceed a single order of magnitude (except the highest value, which really only means “this story is too big”), they don’t include zero, and they don’t use values that imply false precision, like big numbers ending in zeroes, fractions, or numbers with decimal points.
  • 3. If the numbers are close together, say 2-3-3-5-3, then a value in the middle is taken, like 3. In a case like 3-5-3-3-5, we might go with 5.
  • 4. If there are any outliers, the team pauses to discuss the reason for the outlier. For instance, if the numbers are 2-1-8-2-2, the team will want to know why one person thought it was an 8. If the numbers are 8-13-8-8-2, the team will want to know why one person thought it was a 2. Then the team repeats the procedure. Once they get a reasonably close set of numbers, they write it down and move on to the next story.
  • 5. If the story is “too big,” it means the team lacks clarity about the story. For instance, if they got 13-13-8-5-13, they might collaborate with stakeholders to improve their understanding. Then they size again. If the story is still too big, they split it. They repeat this until it’s possible to get a gut feel for the relative size of all the stories, and the work is broken down into reasonably-sized chunks.

Full disclosure: I’ve seen other things happen, too. That’s just an example.

You can see there is a sort of informal “estimation” thing happening here. But more importantly, the team is using the process to ensure they have a common understanding of the scope of each story. For a novice team, sizing the stories serves the dual purpose of estimation and collaboration. For a proficient team, it’s much more about the collaboration; these teams typically use empirical methods to forecast their work.

But it’s not about the points themselves. That’s sort of missing the…what’s the word I’m looking for?…missing the intent.

Now, if you’ll excuse me, it’s time for me to job now, so I have to car to the office. My only ask is that I’ll have time to coffee first. I need to leverage some caffeine before I road. There’s a lot to solution today, and my spend is limited!

Next Hidden Business Rules in Legacy Code

Dave Nicolette has been an IT professional since 1977. He has served in a variety of technical and managerial roles. He has worked mainly as a consultant since 1984, keeping one foot in the technical camp and one in the management camp.

Comments (2)

  1. Gordon
    Reply

    *pointing*?! I’ve been working on agile projects for many years now, and I’ve never heard of this nonsense!

    I loved your “a thing to do” section though – I’ve certainly seem teams doing pointless (hurhur) activities because they believe that’s what “being agile” means.

    Reply
  2. mike carew
    Reply

    I like this article. It reflects on much of why points are a good way to drive conversation about a story. While I think estimation i important, I find I don’t care about the number, just the way points can help focus the discussion. Once completed the vlaue is in the exploration the team ha been on.

    Reply

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

What is the Worth of a Good Product Owner? w/ Tim Wise

This week, on SoundNotes, we’re featuring another question from a student in one of our Certified Scrum classes. The question came from someone who’s working in an organization that doesn’t see value in the role of Product Owner and isn’t convinced that it’s needed as part of the Scrum Team. The question: What is the […]

How Do I Use Scrum on Data Warehouse Projects? w/ Dave Nicolette

In one of my recent Certified Scrum Master classes, I had a number of students who were working on projects involving migrating from a legacy data warehouse to new data warehouses. Figuring out how to apply Scrum to the work they were doing presented a number of challenges and left some open questions.  Here are […]

Maximizing the Amount of Work Not Done

One of the principles of the Agile Manifesto reads: “Simplicity – the art of maximizing the amount of work not done – is essential.” Okay. What does that mean? Does it mean we should avoid doing our work to the extent possible? Well, not exactly. Consistency Between Lean and Agile Principles Without coming at the […]

Prioritizing the Work to Maximize Return w/ Dennis Stevens

This week, on SoundNotes, we’ve got Part 3 of a trio of interviews with LeadingAgile Chief Methodologist and Co-Founder Dennis Stevens. The series focuses on how to build an organization that can embrace change. In the final episode of the series, Dennis and Dave cover how to prioritize work being done to maximize return. During […]