What is a story point ?

search

Story point is a arbitrary measure used by Scrum teams. This is used to measure the effort required
to implement a story.
In simple terms its a number that tells the team how hard the story is. Hard could be related to
complexity, Unknowns and effort.
In most cases a story point range is

1,2,4,8,16 or X Small, Small, Mediu

Large. Mostly commonly used series is the fibonacci series .

m, Large, Extra

A fibonacci sequence is 1,2,3,5,8,13,21,34,45 . Teams use a modifier version of this which looks like
1,2,3,5,13,40,100. The reason Mike Cohn suggest this is because the original sequence suggests
mathematical accuracy and real projects are not like that.

It is a relative term and does not directly co relate to actual hours . Since story points have no
relevance to actual hours, it makes it easy for scrum teams to think abstract about the effort required
to complete a story.
If you look at the Fibonacci curve it really takes a steep climb . If using this series consider not using
1 and 2.
Use 3, 5,8, 13, 40,100.
But how do you know which story is a 3 and which is a five. In order to do that each team would have
to find a baseline story. It does not have to be the smallest one, but one that all in the team can relate
too. From then on all sizing should be done compared to that baseline.
This also creates a lot of confusion as most scrum masters who come from a PMP background
relate this immediately to hours.
Story points do not relate to hours. So lets just not compare them. There is another technique called
ideal hours which can be used.
Story points creates lots of vagueness to your agile process. For every team, story size could mean
different things depending on what baseline they chose. IF two teams are given exactly the same
stories one can say their velocity is 46 and the other can say 14. Depends on what numbers they
chose
So if you want to compare velocity between teams thats a really bad idea as comparing velocity is
like comparing apples and oranges. S o do not compare velocity across teams.
If you really have to track time then dont use story points at all,
Related
About these ads

What are different way to size stories? Why do we do story points, not hours?In "Agile Practices"
Are you failing with Agile, Here is a checklist to help you fail?In "Agile Practices"
What is Velocity in a scrum teamIn "Agile Practices"
BY EDITOR IN AGILE PRACTICES, SCRUM ON NOVEMBER 13, 2007.
WHAT IS VELOCITY IN A SCRUM TEAMWHAT IS A TEAM GROUND RULE OR TEAM WORKING AGREEMENT

45 Comments
1.

Himath
NOVEMBER 24, 2007 AT 8:28 PM

One issue Ive encountered in using hours as a measure of effort is, it can be very subjective when
using for estimates. In Extreme Programming (XP), developers need to estimate the effort for the
stories. The effort in hours could vary from developer to developer. We could attempt to overcome
this issue by using story points which can be used as a relative measure between stories. After a few
iterations, it would be possible to calculate the equivalent effort in hours per story point.
REPLY

Jim

JANUARY 16, 2014 AT 3:59 PM

Id disagree with your last sentence. The SPs (Story Points) assigned to a US (User
Story) would necessarily vary based on the assigned developer, since they encompass
unknowns, and each developer presumably will have a slightly different skill level in
each area of development. Some might be light in Django, yet stellar in Flask, etc.
Also, the reason for a higher SP rating will likely vary from one US to the next. On my
last project, we used the SPs to judge the level of certainty we had when making our
task estimates. A US with 13 SPs wouldnt be surprising if it slipped into the next
sprint, whereas a US with 2 SPs was presumed to be fairly close to the estimated time.
REPLY

2.

Joe
JUNE 2, 2008 AT 5:27 PM

Nice description of the story pointmy team just started using SCRUM to manage our new product
line and this post has really helped. Thanks!
REPLY

3.

Poos
AUGUST 12, 2008 AT 11:00 AM

I didnt get what do you mean by pairing hours You are talking about 2 resources work at a time
[Pai programming] ?
Thanks
REPLY

4.

Federico
SEPTEMBER 23, 2008 AT 9:13 AM

8 working hours? They dont eat, talk, think? Auch

REPLY

5.

Bhavin H. Joshi
NOVEMBER 19, 2008 AT 6:31 AM

Hummm
Quite interesting!
Ill calculate the hours per story point for my team.
REPLY

6.

Ian Suttle
NOVEMBER 26, 2008 AT 6:15 PM

Thanks for the post. While I agree calculating story points to hours is interesting its also a bit
inaccurate as story points are a relative means of estimating. I might estimate something to be a 20
and it takes me 4 hours, and estimate another thing as an 8 and it takes me 6 hours. 28 total points /
10 hours = 2.8 hours / point using your formula. If I apply that to just one story Im likely not accurate.
For instance, if I wanted to say I have a story which I estimate a 20 and believe Ill spend 2.8 hours /
story point, Ill plan for this story to take 56 hours. But in the example earlier it really took 4. Why?
Because its relative and by giving it a 20 Im saying either a) I dont know enough about the story to
be more accurate, b) theres a lot of risk involved, or c) its a lot of work. Story points should really be
used for longer term estimating (I believe Mike Cohn suggests the same) and not short term. Its a
trending tool of sorts. If I really need to know how many hours or days something will take Ill break it
down and try to get an estimate in hours or days for that task. Let me know what you think about
my post on story points.
Thanks again!
Ian
REPLY

editor

DECEMBER 14, 2008 AT 4:53 PM

Ian,
Story points are very useful way to estimate at a gross level / release level. Most useful
at a release planning level. In a sprint planning I use it as a tool that can make the
planning process efficient.
After the capacity plan is done, the team has an idea. I generally ask the team to pick
the first few prioritized stories and size them quickly. This starts a communication in
sprint planning between the scrum team and product owner. I think this is the biggest
benefit i get out of using story points and sizing.
Instead of this if we use time, the conversation take a different turn. I think in the end it
does not matter if a small take 40 hours or a large takes 30 hours. What matters is
team used the card and conversation to build software in the two or three weeks and
delivers value to the product owner.
REPLY

7.

A nice iPhone tool for agile development - Jorge Manrubia

FEBRUARY 16, 2009 AT 11:02 PM

[] members of the team chose a card that represents their estimation. We use story points in the
set proposed by Cohn []
REPLY

8.

Jacob Karma
MARCH 23, 2009 AT 8:45 PM

Hi, I just wanted to mention that we have never used story points and I still dont see the value of
them. Your post does a good job of explaining what they are, and thank you but I would love to
hear your thoughts on what the whole point is.
REPLY

9.

Kristen - CSM
DECEMBER 4, 2009 AT 11:54 PM

I have joined an organization that has been scrum-like for approximately 18 months. Every one of
their teams struggles with story pointing. Many of the team members do not see any value to story
pointing (as per Jacobs post) and are unable to differenciate story point from time.

As a seasoned Scrum Master a team with a stabilized velocity is valuable to me so that I can size
up a release quickly and at the high level accurately enough to predict if we will meet dates, to
determine dates if scope is set and to keep my upper management highly enformed.
To stop team members from getting hung up and stuck on a story point relating to time, I simply
removed the number. We no longer use cards and numbers. We simply size the backlog using
ExtraSmall, Small, Medium, Large and ExtraLarge. We have a baseline Medium story which we use
for each and every pointing session to start our triangulation for new stories.
For me, I have the numbers assigned to each size, XS-3 | S-5 | M-8 | L-13 | XL-20. Anything over an
XL is not a sprintable story for us and can be tagged with a 40 or 100 but basically they need to be
broken down and we dont entertain them into our sprints. I found the meetings less confusing, less
frustrating for teams, more effecient and I still have a velocity calculated with each sprint.
REPLY

10.

Jim Christensen
MAY 7, 2010 AT 5:06 PM

A rather unfortunate choice of words. Story points are not random, they are arbitrary. That means
that they may be consistently applied within projects but not necessarily between projects.
REPLY

editor

JUNE 11, 2010 AT 1:13 PM

thanks fixed
REPLY

waqar ahmad

OCTOBER 1, 2014 AT 10:12 AM

good point

11.

Mike Amy
AUGUST 19, 2010 AT 7:43 AM

Isnt estimating the amount of effort required to implement some functionality basically equivalent to
the Halting Problem? All you have is a team of developers running the program of development,
with the requirement as the data.
In that case, it is clearly attempting something that is (already proven to be) impossible, as this
problem is undecidable in the general case. Even if we simplify it to the K-Bounded version of the
Halting Problem, its still NP-Complete.
Sleep well
REPLY

Steven

OCTOBER 7, 2011 AT 4:06 PM

By that logic, it is impossible for me to estimate the amount of time required to do the
dishes. I am a washer running the program wash with the pile of dirty dishes as my
data.
The halting problem was shown to be unsolvable for all possible input / program pairs
by a general program. In other words, no one program can solve all problems. There is
no proof that the halting problem is unsolvable for each individual input / program pair.
REPLY

12.

Biren
APRIL 27, 2011 AT 5:49 AM

Well, I am new in Agile and trying to use in development. At the end of your explanation, you suggest
not to use story points for time tracking. Is there any other ways to track time? Can we just assign
time to user story instead of story points?
REPLY

13.

Amit Mujawar
MAY 28, 2011 AT 3:50 PM

has anyone of you read about FPA (Function Point Analysis)? Its sad that the new age software
engineering practices are reinventing the wheels. Though I am not a fan of FPA and have seen it
unfit for most of the projects using new technologies, the idea behind FPA is something which is
most logical when it comes to sizing of a feature or a product an absolute measure which can be

factored into other metrics like no. of hours using company specific historic data like dev. productivity
when using JAVA or .Net for a single Function Point.
I think by story point, we really are doing the same thing trying to capture an absolute measure for
a feature so that we know how big/small it is. Directly relating it to no. of hours may not be that
simple equation since it depends on many factors like which technology, how productive the team is
etc.
REPLY

14.

Frank S
AUGUST 31, 2011 AT 7:20 PM

I think the whole point of Story Points is, as Mike Amy suggests above, to engage developers in a
pointless and impossible task, but make the whole endeavour as obfuscated and confusing as
possible, so that everyone feels as though they have successfully estimated something, when in fact
no useful measure is achieved at all.
Story points are no recognised or convertible measure. They are directly equivalent to magic beans.
By estimating in magic beans, but by surrounding magic beans in pseudo-scientific literature and
pseudo-technical doctrine, magic beans become (became) an accepted currency in which
reassurances and promises could be expressed.
In short, it is a load of rubbish that is the fruit of a post-dot com bubble generation of children who
believed that real wealth grew on the tree of dollar debt funded iPhone apps, mashups, ajax, json ,
and all the other nonsense that once upon a time might have evoked a life changing IPO but today
just looks less and less like something that can be eaten or pay the mortgage..
REPLY

Josef

JANUARY 8, 2013 AT 10:10 PM

So it is rubbish because you fail to see any value with it?

I have used it successfully. When the developers in hours estimated the same task
very different, but still correct (the experienced programmer would not spend more
than 2 hours on a task that will take 20 hours for the beginner) it was a necessary step
for group estimation to use story points. Now they could discuss and agree (they both
think that 3 sp is reasonable even as the experienced programmer think of it as 2h and
the beginner as 20).

It is important to remember that the team is not really putting points to the stories. The
are comparing them to the history of previous stories. Imagine all previous 3 sp stories
in a 3-group, all 5 sp stories in a 5-group etc. Now, for the story to be estimated, where
does it fit? In the 3-group or the 8-group or maybe the 2-group. For us using story
points was easier, faster and more convenient than hours.
REPLY

Akaash Mukherjee

JANUARY 8, 2014 AT 8:08 PM

This is totally why the idea of using story points to estimate hours as if one
could approximate the other doesnt make sense. Each developer will move at
a different speed. The only way to make an equation relating story points to
time would be to have developer-specific equations.
15.

Confluence: Blue Glue

OCTOBER 14, 2011 AT 2:10 AM

AGILE Capturing Requirements Epic Stories, User Stories, Technical Tasks

Introduction In the Agile world the term INVEST is
REPLY

16.

Scrum Debates: Story Pointing Bugs | SoftArtisans, Blogged Scrum Debates: Story Pointing Bugs |
The Cathedral and the Bizarre
DECEMBER 13, 2011 AT 10:19 PM

[] But one such problem that our Product owner recently brought up is, Should we really be story
pointing bugs? And the answer, of course, is well, actually, no one can really agree on an []
REPLY

17.

Lean as the solution to scale Agile Methodologies #hypertextual

APRIL 25, 2012 AT 11:23 AM

[] Lead Time and bye Story points. While story points are a perfect metric for a couple of agile
team it just does not scale up to []
REPLY

18.

Confluence: Agile Process Improvements

JULY 11, 2012 AT 8:08 PM

Agile Vocabulary
The following is the CDI approve and accepted term
REPLY

19.

Stephen Forte`s Blog

JULY 23, 2012 AT 10:41 AM

Beyond Agile Estimation Part I: Measuring Key Data Points

REPLY

20.

Define stories | 747mediagroup

SEPTEMBER 5, 2012 AT 4:05 AM

[] What is a story point ? What is a story point ? November 13, 2007 19 Comments. Story point is
a arbitrary measure used by Scrum teams. This is used to measure the effort required to []
REPLY

21.

More Things From The Past Shiggy Enterprises

NOVEMBER 29, 2012 AT 11:24 AM

[] estimates a number of existing work units in an arbitrary unit (e.g. Story Points maybe this post
will help understanding it.) related to there capacity and their time frame []
REPLY

22.

Shubham Goyal
JANUARY 4, 2013 AT 10:44 AM

Hi,
There is a typo in the Fibonacci sequence in the article. It should read 1,2,3,5,8,13,21,34,55 instead
of 1,2,3,5,8,13,21,34,45 as is written in the article. The difference is in the last number (55 instead of
the erraneous 45).
REPLY

Aravinda Joisa

JANUARY 24, 2013 AT 8:36 AM

Typo is excused. I really appreciated the article..So do you..I guess!!!

REPLY

23.

keyword 2
JANUARY 24, 2013 AT 6:26 AM

I just could not depart your site prior to suggesting that I really enjoyed the standard info a person
provide for your visitors?
Is going to be back often in order to check up on new posts
REPLY

24.

DevOps How do you measure team success? | Dev Ops Guys

APRIL 18, 2013 AT 1:28 PM

[] have re-worked the old function point or Agile story point concept by adding a business spin
and came up with Business Value Points. (As an aside why []
REPLY

25.

The Most Powerful Word Known to Mankind

JULY 22, 2013 AT 10:00 AM

[] were early signs of the release going off track, with the sprint burndown lagging, the story points
increasing significantly, and an unusually large amount of questions being asked about the new []
REPLY

26.

The Most Powerful Word Known to Mankind - WebPronto

JULY 22, 2013 AT 10:07 AM

[] were early signs of the release going off track, with the sprint burndown lagging, the story points
increasing significantly, and an unusually large amount of questions being asked about the new []
REPLY

27.

Woody Painter

AUGUST 21, 2013 AT 9:09 AM

Story points are the modern version of arguing how many angels could fit on the head of a pin.
Proof: sometimes you have to re-estimate a task several times and youll find more and more story
points as you start finding things you didnt think about when you first story pointed. Therefore story
points are inaccurate. Its a load of bunk. An accurate estimate of a programming task takes as long
as just doing it, therefore you should keep estimating to a bare minimum. I am amazed at how
people who are supposedly able to deal with logic (programmers) fall for this idiocy.
REPLY

28.

Sizing, Estimation and Forecasting | radtac

JANUARY 15, 2014 AT 9:40 AM

[] business didnt understand the concept of Ideal days, so we re-branded them as Story Points,
where a story point equates to an ideal day. This didnt really help though as we never built a []
REPLY

29.

Gerald
APRIL 15, 2014 AT 1:21 PM

Ha ha ha i love the way the discussion turned. Im on this site to understand how people could
complete a project within timeline and budget using scrum/agile because all I have seen is failure.
And I reach this topic and now I understand. People invented story point like candies because
they do not want to commit on a number of days to complete a task. Result: we have now PM that
are not able to tell you how much have been done, the remaining to do, cost at completion and new
estimate completion date.
Why? because they estimate using candies
Please tell me Im wrong! Tell me there is a way at the beginning of an agile project to predict when
it will be completed! Thank you
REPLY

30.

Josef
APRIL 16, 2014 AT 5:25 AM

@Gerald: You are wrong, but not in the way you think. You know how much time it will take when you
know how much money the customer wants to put in the project (so you will always end the project
on time, and you can tell the date in advance as time is fixed), but you cant tell what the outcome will

be. The scope is not fixed. The scope is discovered together with the customer during the project (by
prioritizing backlog and implementing backlog items).
REPLY

Gerald

APRIL 16, 2014 AT 11:11 AM

@Josef, thank you for your answer. My problem is I work for a software vendor. Our
customer, at the moment he signs the contract, wants to know HOW MUCH and
WHEN AM I GOING LIVE. He has already his requirements that he puts on the table.
With a proper PMI-PMP I was able to answer. Now, with a team using scrum, I got no
answer? Why cant you give me a date? Because we are using scrum! its better!
I see the benefit of scrum for internal development, but is it really applicable for a
vendor? Thank you
REPLY

Josef

APRIL 16, 2014 AT 11:55 AM

If the customer have already a fixed scope with detailed requirements, then a
large benefit of agile development is lost and I think it might be less friction if
your team dont use scrum in this project.
Agile development might solve a lot of problems that have now already been
implemented in the requirements. (They have made decisions based on
earlier software/operation/guessing etc.) You need some other method that is
better at running against a fixed scope (I think most peoples experience is
that scrum is not the solution).
Of course the team might use scrummish methods internally, but they
should not have the delusion that they can run scrum, and they still need to
make extensive planning in advance so they can come up with dates etc.
Agile is a good way to share responsibilities and makes the developers take
part in solving the real problem for the customer, not just implementing
software. I think that is why developers tends to be very positive to agile
methods. The customers on the other hand might not be as interested in
sharing operation responsibilities and would prefer that the developers just
produce code according to the specification. They dont understand that what

the developer is really doing is refine those specifications even more so that a
compiler can do the work.

Renier PretoriusRenier

AUGUST 18, 2014 AT 2:41 AM

@Josef and @Gerald. As a software vendor myself, Struggle with the exact
same issue. The biggest problem is that the client comes in with a business
problem, not a functional specification. Spending months trying to analyze the
business problem and converting it into a detail functional spec with pseudocode and approved algorithms is a highly risky endeavor as by the time this is
done, the business context have changed and many of the assumptions
made during the development proved wrong. This makes the agile process
very appealing, BUT how do you contract for agile? I can tel the client my
team will cost them x dollars for the year, but what will they have by the end of
that year? What benefit will they derive to justify the expense? If it was a web
site where you need to add a button to do this or a form to do that, breaking it
up into US is fairly simple, but develop a detail production scheduling
application with direct operator and scheduler interfaces, then you only have
value once the system can do the whole job not just part of the job really
well. For agile to work you need an acceptance of an open-ended scope on
both sides (developer AND client). Doing this commercially is just near
impossible try and get that through Supply Chain!!

Roman

APRIL 19, 2016 AT 5:42 PM

If you were able to estimate and answer accurately what a SW project will
cost and when it will be done without story points, then dont use story
pointsuse what is successful for you. Id also suggest you write a book on
the topic, become a multi-billionaire and then turn your talents to solving world
hunger or finding cures for all known diseases.
The point is, SW estimation is always inaccurate. The question story points
answer is how do you get a good enough estimate to plan work without
wasting time estimating in millimeters with a yardstick while measuring
continually moving requirements, resources, technology, tools etc. Comparing
to historical data of something similar in complexity while acknowledging the

larger it is, the less accurate your estimates will be, seems to be good
enough. Thus Fibonacci based story points.
For actual time and cost estimates from story points, remember in AGILE,
story points are team based, not individual based, and assume some level of
constant team makeup, else they need to be adjusted. So you would need to
get team by team velocity, story point totals per team for the project and
salary of team members.

31.

Sure software methodologies appear different. But keep in mind what they have in common. |
Praxtime
APRIL 29, 2014 AT 6:18 AM

[] these adjustments gracefully. In fact, before I started writing this post I thought scrum used story
points to indirectly estimate work because the human mind was better at relative estimation than []
REPLY

32.

An equation for evaluating the adoption potential of a new product | Breaking Glass by Rishi
Dean
JULY 8, 2014 AT 3:19 AM

[] For each step in the process assign a multiplier based on the difficulty for the user. It doesnt
truly matter your units, once they are consistent across the left and right-hand side. For this, I like to
use a Fibonacci set, similar to the method used for assigning story points in an agile process. []
REPLY

33.

Mike Anderson
NOVEMBER 12, 2014 AT 4:14 PM

In my experience i have changed the way i handle story points -vs- estimating a million times usually
due to working on different projects, teams, organizations and reading blogs and posts. I think
everyone who has done this long enough can honestly say that there is not one concrete way that
will work for everyone, and that is absolutely fine. With that said, here is my approach and hopefully
will work for some and probably wont work for others. Once my team comes up with a baseline for
story points i have them break down the story into their sub-tasks and put the estimates on the subtasks. The reason i do this is not to compare one developer to another but when we finish tasking out
all stories we can see if their estimates actually fall within their capacity. There are tasks that might

not have points e.g. Spikes but I do put time on this, QA deployments, if we do 10 QA pushes
throughout a Sprint each one might take 15 minutes so that needs to be estimates in scheme of
things. Production Support, If we have a Production deployment during a Sprint, well then that takes
time. I have not always had great success coordinating with a WebOps team so this might take an
extra 2 hours of a developers time. Everything adds up. So, at the end of the tasking session which i
make sure is complete during Sprint Planning Day i take one last look at the Capacity and Estimates.
If it is way over we have one last conversation with the Product owner and come up with a solution,
either pull a story or break a story up into smaller increments. Either way, i use both estimations and
Story points.