That's How You're Using Story Points? No Way.
- Share
-
- |
Read later
Reading List

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.
Do all agile teams understand how story points work? Apparently not. A recent post from Mike Cohn of Mountain Goat Software reiterated that estimating features with story points is about gauging relative effort, not about ranking features in order of their complexity.
To illustrate the difference between ordinal ranking and relative effort Mike used the example of buying a car. A team using ordinal ranking would list the cars from least expensive to most expensive assigning one additional point per car so that a Tata Nano would be one point and a Bugatti would be 10 points. The example illustrates how using story points to rank a product backlog will lead to a misunderstanding in terms of cost; the Bugatti being nearly 960 times the cost of the Nano.
But why did this come up? Were there agile teams out there who truly didn't understand that estimation of features with story points was about gauging effort, cost...not ranking features? That's exaclty what Thomas V asked:
I have to ask: what prompted you to write this post? Are there really people doing this?
And Mike Cohn confirmed. Yep, folks are apparently doing this:
Hi Thomas- Yes, oddly people are doing this. The prompt was an email on Saturday from someone I respect who told me he does this. I was quite surprised. I can’t see a single reason to rank product backlog items in this way, but yes it is done.
Turning it over to our readers; have you seen teams misusing the story point estimation technique? Have you experienced teams using story points to rank...rather than estimate a backlog of features?
Rate this Article
- Editor Review
- Chief Editor Action
Hello stranger!
You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think
Story Point
by
Theron James
Re: Story Point
by
Chris Goldsbury
Re: Story Point
by
luke stephenson
As for the standard for comparison, all the work the team has historically estimated using story points and completed is the best comparison you can find for determining what you can achieve in the next iteration / release. If the team has estimated all of the stories and manages to complete X story points one iteration, then that serves as a very good indicator of what we can achieve the next.
Theron.. I've also heard so many teams linking story points back to a unit of time during estimation meetings.
Re: Story Point
by
Chris Goldsbury
Take an example:
4 stories are put into an iteration. The team has gauged through time that they can run at 120-140 points an iteration ( velocity ).
Story 1 = 10 points.
Story 2 = 60 points.
Story 3 = 40 points.
Story 4 = 20 points.
They complete all the stories except Story 1. So, was story 1 estimated inaccurately? No. The team just mis-estimated how much work they could do in an iteration. Story 1 will never actually be inaccurately estimated *UNLESS* you are tying it to time/cost.
Perhaps Theron just meant that story points provide more accuracy in estimating velocity, not necessarily accuracy in estimating any one story.
Sorry for any confusion. You're right. I don't know as much as Mike Cohn. Never will.
Re: Story Point
by
luke stephenson
I don't claim to be an expert though :)
Yes
by
Dave Nicolette
The two most common examples have been described by others already: Equating points with time, and using story sizes to rank the backlog. What the latter has meant IME is not exactly "ranking" the backlog, but rather scheduling stories into the release. I've seen teams that chose the smallest stories so that they could maintain the appearance of progress. That left larger stories unaddressed, regardless of their actual business priority. Apparently they found this easier than learning how to split the larger stories. Go figure.
It all evens out in the wash
by
Tommy Norman
On the issue of accuracy that came up, story points and time based estimates are both fallible since they are provided by we the imperfect human. Where story points (and iterative development/planning) provide an overall better chance for accuracy is in the fact that you are constantly looking back at your past performance and adjusting your plans based on empirical evidence. A bloated velocity in one sprint due to a poorly sized story will only add a minor blip on your overall velocity average so if it is not a common occurrence then it does truly even out in the grand scheme of things.
If your team makes sure to frequently compare stories they are estimating to stories they have done in the past to triangulate their relative sizes, then you should have less instances where items are significantly larger or smaller than originally planned. The trick is to make sure they look at the complexity and activities around the story and not the hours. But of course this will happen from time to time and again it should not cause a significant issue with your overall release planning.
Re: Story Point
by
Chris Goldsbury
Re: Yes
by
Chris Goldsbury
So in your example a team uses the estimates as a way to tackle the easy stuff first. How does that play out toward the end of the project?
Re: It all evens out in the wash
by
Chris Goldsbury
Re: It all evens out in the wash
by
Tommy Norman
I would be careful with the term "tracking actuals". Part of the charm of story points is that they are not supposed to be precise. The actual hours of work for a story that is a 1 may have a decent amount of overlap into the range of actual hours worked for a 2 point story and so on. Striving to be consistent in how many you commit to in an iteration/sprint is a better goal. As I mentioned before, the time boxing and incemental nature of practices like Scrum go hand in hand with this type of estimating. Story pointing a traditional waterfall project would make very little sense because you would not have built in check points in which you routinely inspect and adapt.
Re: It all evens out in the wash
by
Tommy Norman
Re: Story Point
by
luke stephenson
I wasn't trying to imply a blanket rule that a lower estimate is accurate and a higher estimate is inaccurate (and will need to be more careful of my wording if it came across that way).
Story point
by
tushar jain
Few of the factors I have though of:
Technical complexity
Business complexity
Efforts required to complete the story ( dev +test+ deployment + ...)
Dependency within scrum team
Dependency within project (A project might have multiple scrum teams)
Dependency across different projects ( some of the projects might be running on waterfall model)
Clarity in requirements
Clarity in scope
Urgency of story