Story Point is a measure of relative bigness used by Scrum Teams mostly. They use this before the sprint starts to indicate and figure out how big or small a given feature is.
For example: If I were to list the following fruits and ask you to line them up left to right based on the complexity of eating the fruits and enjoying them how would you line them up.
Banana, Cara Cara , Apple, Pear, Mango, Grapes, Pinepapple.
You probably put grapes as the simplest as you tried to line up the fruits from simple to complex. Why Grapes? Maybe because its small, easy to wash, quick to eat etc.
Once you line them by complexity you can give any number sequence. Most teams tend to use a modified Fibonacci.
1, 2, 3 5, 8, 13, 20, 40 100. The unreal numbers 20, 40 100 signify the fact that when its is unknown it really does not matter. All we need to now is Cara Cara and Pineapple or really complex and not as simple as a pear or Banana.
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, 20, 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 create 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 don’t use story points at all,A Use it for creating
- useful conversations in teams and not to get it right.
- Deciding when to split a story
- Negotiating with a product owner etc.
Be agile about story points. Use it for what its worth. It is error-prone and you can never get it right. The only time you will be right is once the work is actually done.
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 don’t use story points…use what is successful for you. I’d 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.
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 sub-tasks. 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.
@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 pseudo-code 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!!
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.
@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
@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).
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
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.
This is totally why the idea of using story points to estimate hours as if one could approximate the other doesn’t 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.
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.
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
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.
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).
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.
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…..
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.
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?
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.
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.
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.
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.
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.
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.
I’ll calculate the hours per story point for my team.
8 working hours? They don’t eat, talk, think? Auch…
I didn’t get what do you mean by pairing hours – You are talking about 2 resources work at a time [Pai programming] ?
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!
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.