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, Medium, 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,

About these ads

Posted on November 13, 2007, in Agile Practices, Scrum. Bookmark the permalink. 37 Comments.

  1. 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.

    • I’d 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 wouldn’t 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.

  2. 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!

  3. I didn’t get what do you mean by pairing hours – You are talking about 2 resources work at a time [Pai programming] ?

    Thanks

  4. 8 working hours? They don’t eat, talk, think? Auch…

  5. Hummm…
    Quite interesting!
    I’ll calculate the hours per story point for my team.

  6. 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.

  7. 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.

  8. 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.

  9. 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.

  10. 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.

  11. 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?

  12. Amit Mujawar

    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.

  13. 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.

  14. 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).

  15. 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

  16. 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 you’ll find more and more story points as you start finding things you didn’t think about when you first story pointed. Therefore story points are inaccurate. It’s 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.

  17. Ha ha ha … i love the way the discussion turned. I’m 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 I’m wrong! Tell me there is a way at the beginning of an agile project to “predict” when it will be completed! Thank you

  18. @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 can’t 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).

    • @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 can’t you give me a date?” “Because we are using scrum! it’s better!”
      I see the benefit of scrum for internal development, but is it really applicable for a vendor? Thank you

      • 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 don’t 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 people’s 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 don’t understand that what the developer is really doing is refine those specifications even more so that a compiler can do the work.

  1. Pingback: A nice iPhone tool for agile development - Jorge Manrubia

  2. Pingback: Confluence: Blue Glue

  3. Pingback: Scrum Debates: Story Pointing Bugs | SoftArtisans, Blogged Scrum Debates: Story Pointing Bugs | The Cathedral and the Bizarre

  4. Pingback: Lean as the solution to scale Agile Methodologies « #hypertextual

  5. Pingback: Confluence: Agile Process Improvements

  6. Pingback: Stephen Forte`s Blog

  7. Pingback: Define stories | 747mediagroup

  8. Pingback: More Things From The Past « Shiggy Enterprises

  9. Pingback: DevOps – How do you measure team success? | Dev Ops Guys

  10. Pingback: The Most Powerful Word Known to Mankind

  11. Pingback: The Most Powerful Word Known to Mankind - WebPronto

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

  • Tweets

  • Follow

    Get every new post delivered to your Inbox.

    Join 211 other followers

    %d bloggers like this: