What is a story point ?
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
m, Large, Extra Large. Mostly commonly used series is the fibonacci series .
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 that’s 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,
Posted on November 13, 2007, in Agile Practices, Scrum. Bookmark the permalink. 26 Comments.
One issue I’ve 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.
Nice description of the story point…my team just started using SCRUM to manage our new product line and this post has really helped. Thanks!
I didn’t get what do you mean by pairing hours – You are talking about 2 resources work at a time [Pai programming] ?
Thanks
8 working hours? They don’t eat, talk, think? Auch…
Hummm…
Quite interesting!
I’ll calculate the hours per story point for my team.
Thanks for the post. While I agree calculating story points to hours is interesting it’s 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 I’m likely not accurate. For instance, if I wanted to say I have a story which I estimate a 20 and believe I’ll spend 2.8 hours / story point, I’ll plan for this story to take 56 hours. But in the example earlier it really took 4. Why? Because it’s relative and by giving it a 20 I’m saying either a) I don’t know enough about the story to be more accurate, b) there’s a lot of risk involved, or c) it’s 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. It’s a trending tool of sorts. If I really need to know how many hours or days something will take I’ll 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
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.
Hi, I just wanted to mention that we have never used story points – and I still don’t 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.
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 don’t 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.
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.
thanks fixed
Isn’t 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, it’s still NP-Complete.
Sleep well
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.
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?
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.
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…..
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.
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).
Typo is excused. I really appreciated the article..So do you..I guess!!!
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
Pingback: A nice iPhone tool for agile development - Jorge Manrubia
Pingback: Confluence: Blue Glue
Pingback: Scrum Debates: Story Pointing Bugs | SoftArtisans, Blogged Scrum Debates: Story Pointing Bugs | The Cathedral and the Bizarre
Pingback: Lean as the solution to scale Agile Methodologies « #hypertextual
Pingback: Define stories | 747mediagroup
Pingback: More Things From The Past « Shiggy Enterprises