Debunking 4 Misconceptions About Story Points

From the Voices on Project Management Blog
by , , , , , , , , , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.

About this Blog

RSS

View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Roberto Toledo
Vivek Prakash
Cyndee Miller
Shobhna Raghupathy
Wanda Curlee
Rex Holmlin
Christian Bisson
Taralyn Frasqueri-Molina
Jess Tayel
Ramiro Rodrigues
Linda Agyapong
Joanna Newman
Soma Bhattacharya

Past Contributers:

Jorge Valdés Garciatorres
Hajar Hamid
Dan Goldfischer
Saira Karim
Jim De Piante
sanjay saini
Judy Umlas
Abdiel Ledesma
Michael Hatfield
Deanna Landers
Alfonso Bucero
Kelley Hunsberger
William Krebs
Peter Taylor
Rebecca Braglio
Geoff Mattie
Dmitri Ivanenko PMP ITIL

Recent Posts

50 Most Influential Projects: What Made the List?

Urbanization and the High Price of Human Progress

Welcome to The Project Economy

Embraer Reaches New Heights: Lessons From a Record-Setting Jetsetter

The Hunt for the Disagreeable Giver


Categories: Agile


by Christian Bisson, PMP


Story points, while an essential component of agile, are often misintrepeted.
And that’s a problem, as story points are are a vital unit of measure to help
estimate user stories. And stories, in turn, help teams plan their next sprint.
When they’re misinterpreted, story points lose their effectiveness, and they
can even hurt teams because of how they are used.

For the sake of my examples below, I assume teams use the Fibonacci sequence.
Let’s run through a few common misconceptions:


1. It’s about the complexity.

Some teams will mistakenly focus only on the complexity of the user story,
as measured by the required level of training it takes to complete a given
task. If a task is simple but time-consuming, they will assign it a “1.”
This is misguided because in addition to complexity, story points also take
into account effort and risks.

It’s important to factor in all three of these aspects of user stories to make a
proper estimate.

2. It’s about the business value.

Simply put: no.
When prioritizing their backlogs or even deciding to move forward with a
user story, it’s important for product owners to understand that story points
have nothing to do with business value.


A “13” could bring no value while being costly, and a “1” could be a golden
opportunity (a.k.a. a “quick win”).


Some Product Owners assign a “Business Value” to user stories (for example: A, B, C), although not mandatory, it can be used along with story points to help make key
decisions about priorities.

3. One point is one day of work.

Story points are not days, nor hours—they are a separate unit of measure. If
using “days” to estimate user stories works well for your team, then by all
means keep going, but call them days as opposed to story points to avoid
confusion.


4. Story points can be used to compare teams.

This one is a dangerous trap, especially if used by someone who can
influence people below him or her. It’s important to understand that story
points are relative to each person. Even within a team, it can be a challenge
to align initially until they have a few user stories to compare with.

A “5” can mean something different for Team A than for Team B, so
comparing each team’s velocity gives absolutely no value whatsoever. In
fact, it can mislead you into thinking one team is more efficient than
another, which in turn might result in unjustified negative feedback or
pressure to “have high velocity.”


In Summary

Story points are a tool, and like all tools, they’re only as good as how we use
them. If we fall into common trap, using our story points to plan our sprints
will lead us to disaster. It’s important that every member of the team
understands the concept, and that you also take the time to educate anyone
outside the team who has influence over your work, such as upper
management or customers.


Do you know of any other misconceptions around story points?

Posted by Christian Bisson on: January 26, 2019 01:44 PM | Permalink

Comments (12)

Please login or join to subscribe to this item
Good points. But let me say that everything can be reduced to the definition of User Stories which is mostly missing and it is the reason of all evils: by definition of their creators (i have the pleasure to work with them) a story point is "a placeholder to talk about". Because of that Story Points is the "worst" method to estimate in terms of the inherent error is high (no matter the method you use the inherent error is there because estimation depends on information). I am using Story Points due to my stakeholders like to use it but it was a hard road to walk to make them understand what we get as the result of our estimations when using story points.

What is interesting is how recent events have and will influence what you talked about here.

Christian,

Thanks for sharing these tenets of misconception. I'm working with a team to flesh out our agile process on a "use case" mobile dev project. You've given me some great points to talk about. I particularly like #'s 2 and 4.

Helping the product owners to understand these points will go a long way toward more agile/iterative mindsets.

Absolutely excellent information. Most of the teams have issues in calculating story points. Thanks for sharing!

Thanks for sharing your experience and takeaways Christian!
These are all valid points. I like the first point where you suggest to take effort and risk to complexity to the estimation of story points for a user story.
Myself, I am not a big fan of story points, I have used "n-hour focused work person days" (n around 6, to be discussed and agreed with the team) with relative good success in the past. it's a unit that can be understood by most stakeholders, and accepted by the developers. The important is the process by which we reach the estimates, and the understanding that they can be revised as the stories are groomed and broken down further.
Thanks again for sharing and triggering the exchange!

Thanks for sharing

Great article! Yes indeed they are to be a measure of relative solution complexity. Use beyond this purpose courts disaster!

Got the better understanding on story points. Thanks

Thanks Sharing

‪Good clarifications as most teams fall prey to one of these misconceptions ‬

Please Login/Register to leave a comment.

ADVERTISEMENTS

We're going to have the best-educated American people in the world.

- Dan Quayle

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events