Get certified - Transform your world of work today

# Story Points Are a Measure of Effort. Period.

Despite my best efforts to squash it, a rumor persists that story points are a measure of complexity. That rumor is downright wrong. The truth is, the complexity of a user story is unimportant, except to the extent that complexity affects the degree of effort required to complete it.

Let me give you an example. Suppose you and I look at a building a certain distance away. You think it’s a 5-minute walk. I think it’s a 10-minute walk because I’m on crutches at the time we have this discussion.

You and I cannot agree. You are right that it is 5 minutes (for you) and I am right that it is 10 minutes (for me). In minutes, hours, days, etc. the problem is intractable: you and I cannot agree on an estimate because we produce at different rates. â€¨

We can, however, agree that the building is “1 unit of time away.” You’re thinking 5 minutes and I’m thinking 10 minutes when we agree to that estimate of 1 unit—but that doesn’t matter. We’ve found an estimate we can agree on.

Suppose, you then point to another building and say, “That building is twice as far. It’s a two.” You are thinking it’s a 10-minute walk and I’m thinking it’ll take 20 minutes on my crutches – but we both agree it’s about twice as far.

We can agree on an estimate of 2, even though we produce (walk) at different rates. That’s what story points are about.

How would this work if we were only estimating complexity? Walking to the first building or the second building is equally complex. We’d estimate the complexity of walking to either building with the same value—let’s say a 1. What in the world would the benefit of that be? None, right? Complexity is not directly what we estimate—we estimate how long something will take and complexity can influence that estimate.

To continue our example, suppose we point to a third building. It’s physically the same distance as the first building (which was a 1). So we might want to call it a 1 as well.

Except to get to the third building we have to walk on a very narrow path over a nasty plunge into hot lava below us—the path is perhaps a foot wide or whatever you think of as narrow but traversable.

I think we can agree that walking to that building is more complex because even though it is physically the same distance away as the first, it will require more concentration and balance to walk there. We will each walk more slowly to that building—so we might estimate that effort as a 3 or a 4—because we think it will take 3 times or 4 times as long to walk to that building as it would the first building.

We are still estimating effort—complexity is a part of that discussion, but is not the thing we are estimating.

If we were only estimating complexity, I have no idea what number I’d put on that narrow walk. I really don’t—how does one estimate complexity? The only way I can quantify complexity is as it affects something else.

In the case of story points, we estimate the effort (time) to do a thing—that effort can be affected by risk, uncertainty, or complexity. So let me say it as clearly as I can: story points are an estimate of effort, not complexity.

Do you want one short tip each week from Mike to help you succeed with agile?

### Article Rating

Current rating: 4.7 (20 ratings)
 Karen It has been a misconception through out that the story points are unit of complexity and not an unit of effort. The example used has very well explained the difference. The complexity is one of the factors that would affect the unit of effort. Effort has always been thought of as number of hours it may take to complete a task. 8/26/2016 10:08:32 PM

 Mike Cohn Hi Rasmus--If the distance to something is something is doubled (e.g., a building we are walking to) the effort to walk there can be thought to have doubled (it will take twice as many footsteps). But complexity won't have increased. I just searched for a definition for "complex" and the first that popped up was "the state or quality of being intricate or complicated," so let's go with that for now. You can think of "complex" as having to do with the number of "intricacies" in the work. Perhaps the number of things that could go wrong. 12/30/2015 3:12:16 PM

 Rasmus Rasmussen I am thinking that if distance is doubled, then the complexity is doubled, so I guess I am using the wrong word but think the same, right? What is meant with the word "complexity"? 12/17/2015 12:34:58 AM

 Mike Cohn Good point, Drew.People bring all sorts of personal biases to their understanding of a word. 8/23/2015 11:20:47 PM

 Drew Mills This is an interesting article. I think you may be missing the point of why people (scrummy people) are trying to avoid using the word effort. They really mean Effort, not effort.Effort (upper-case 'e') is a term that is often used to measure the amount of personnel time allotted to a project or project feature when using traditional Project Planning. "Effort, when being accounted for and quantified in a time and labor budgetary attempt is customarily presented in terms that include but are not particularly limited to staff hours, staff minutes, staff days, staff weeks, staff months, or, for particularly long projects, even staff years. " -- project-management-knowledge.comI would be happy to use the word 'effort' when describing story points, but I would never use the word 'Effort'. That puts people right back into the mindset of my time vs your time. Using the word Complexity gives people another yardstick other than Effort. Size, Difficulty, Toughness: they are all useful terms as long as we try to avoid the time problem. The word 'effort' would also work as long as we aren't trying to overcome the 'Effort' hurdle. 8/18/2015 10:57:58 AM

 Mike Cohn Hi Manuel--If you're no longer on crutches, all you would do is let velocity take care of things. I call velocity "the great equalizer."The ratio between buildings still holds -- walking betwen this building and that building still takes twice as long -- so I don't need to re-estimate. 6/3/2015 5:39:13 AM

 Manuel I am realy agree in most of the Points in this artical. What i do not get is, what is the estimating for Story one if you do not have crutches anymore (you have learn you getting faster). What is the estimating then? Do you estimate 0.5 because you are faster whithout crutches or is the estimating still a 1 but a new "1" with faster velocity? What is about the Story 3 in this case. Could you adapt the new velocity here or do you have to re-estimate? Thanks for answering. 6/3/2015 1:05:39 AM

 Mike Cohn Thanks, Aris.You are correct that story points are not merely the time involved. Story points are a function of the effort to do the work as well as the risk, uncertainty, and complexity involved in the work. For the example you give of a bunch of little rocks vs. a huge stone, I'd say this: We can somewhat ignore the things like risk, uncertainty and complexity there. So this example will boil down largely to time. (We could say there's the risk I hurt my back on the boulder but let's ignore that.)You told me it takes 5 seconds to move the boulder. But let's assume I'm exhausted afterwards. I won't be tired for long but that thing was *heavy* so I pant and catch my breathe let's say for 55 seconds. Total of one minute.Let's say that moving all the little rocks takes 5 minutes. You called it "effortless" but that's just a phrase. It takes *effort*. It's just mindlessly shoveling the rocks a meter away. After 5 minutes I finish that and feel as rested as I started. I could have kept doing it or I could move on immediately (no rest needed) to the next task. So the time to do the two tasks and finish ready to do the next thing is 1 minute for the boulder and 5 minutes for little stones. So I'd put a ratio of 5:1 points. Note that this is a crappy example because (a) it's a task not a story (only one person doing the thing) and (b) it's been stripped of everything but time so there are no advantages to points. I strongly suggest you see my blog and these specific posts:http://www.mountaingoatsoftware.com/blog/its-effort-not-complexityandhttp://www.mountaingoatsoftware.com/blog/the-main-benefit-of-story-points 4/10/2015 11:48:27 AM

 Aris Hi Mike,Good article. I really want to be a great SCRUM master but I still struggle with the concepts of SCRUM. I hope to learn a lot from your posts.Regarding this article, story points are an estimate of effort but it's not exactly an equivalent to a specific amount of time like building 1.How would you estimate in story points a case like this.You have 1000 very light stones that you need to move to a location 1 meter away, against 1 huge stone? Clearly the effort required to move a huge stone is so much more but once you do it, then it's done in 5 seconds. Moving each of the thousand rocks is effortless, but consumes much time. As you know, this is just an analogy and you could talk about the rock literally, or focus on the effort scenario. Thanks! 4/9/2015 8:12:23 PM

 Mike Cohn Thanks, Anand.For uncertainty, simply adjust the estimate up or down based on the uncertainty. Consider a commute of walking home from work. That's predictable and you say 20 minutes is your estimate. If you have to take a train, you'd factor in uncertainty--it might normally be a 10' commute on a train. But sometimes the train is broken and you wait for the next train. Sometimes the train is late, etc. So, you might estimate it as 15', which would be your average commute time on the train. It has a wider standard deviation than walking, if you want to think of it that way. Generally, I ignore dependencies when putting story points on stories. Dependencies can be dealt with as part of the sequencing of work. But the dependencies don't increase the *effort* involved in the work, which is what the points are about. In all my years of doing this, I can't think of a time that has burned me. It's theoretically possible it could but it never has. 2/3/2015 7:14:08 AM

 Anand Swaroop Mike this is great example and i really admire the way you have explained it. Story point vs Hour mapping debate is pretty common and this is the first question which people ask when they try to transition to agile way of working.Could you also tell us how uncertainty/ Dependencies will affect your estimation? 2/3/2015 5:03:45 AM

 Mike Cohn Hi Petr--I don't get the issue as that seems to make a great argument for why points are about effort. If something is easy but will take a lot of time you'd want a large number of points. Otherwise you could have a project that could take a million years and you'd tell your boss "2 points" and he'll say "great, I'll expect it tomorrow." 1/15/2015 8:08:02 AM

 Petr Hi Make, there is a thing that bugs me. What about stories that are simple but takes a lot of time (e.g. adding notNull constraints on 500 columns in various tables). It would be simple, monkey job but it would take time. I tend to say it would be 1-2 SP as the effort is not great... 1/15/2015 6:02:26 AM

 Mike Cohn Thanks, Ranata. 12/31/2014 10:28:59 AM

 Ranata Johnson Mike,Thanks for a great example and this is one paradigm shift that many of my own teams struggle with. The problem I have with my teams is they want story points to equate to hour estimates. Complexity, risk, and skill don't seem to matter with how they want to estimate. So I appreciate your answers above. I have team members who just think Effort means hours so I try to avoid using the word effort. Effort means more than just hours and I don't know how to help them make the paradigm shift. For some just defining tasks and estimating hours is good enough to establish the points. They have to think about it that way. Your example above is great and I will share it with my teams. Thanks for the example. It's a tough topic for some teams. 12/30/2014 3:52:22 PM

 Jen O'Farrell this has to be the best example i have seen, thanks Mike! re:revising estimates, is there something in this model that accounts for improvements in estimating accuracy - as in the case of a less experienced developer? is it the "peer pressure" factor of the planning game? 11/10/2014 9:34:03 PM

 Deepak Joshi Hi Hemant,As Mike indicated- "Don't compare to a story with a known bad estimate." I fully agree with this.In my view there are a few possible risks if one continues to compare each story with story 1 (a story with minor bad estimation):1.If someone continues to keep story 1 in his mind then, for each story estimates he will try to associate story 1 or the circumstances with the new story. This may lead to bad estimations as being focused on story 1; he may skip to visualize other vital/hidden areas of new story. 2.He may start suspecting and comparing each story for such uncertainties/risks and hence unnecessary delay in estimations.3.He may start losing his confidence during estimations.4.He may try to indicate such incidences to other teammates during estimation workshops and this will create an uncertainty among others also.Also, estimating stories is teamwork so go-ahead, participate in estimation with other teammates with fresh mind keeping away story 1 :-). This will certainly lead to better estimates. 11/7/2014 4:44:06 AM

 Hemant Kothiyal Hi Mike,I am big fan of yours, And i read your reply multiple times because i know you are trying to explain something important that i am not getting.I tried many times to not compare story3 with story1, but again & again i am going and comparing with story1 and story-X and story-Y, BUT not able to avoid story 1 comparison.I also thinking that in future for similar story4 i will start comparing with story3 not story1.Also if we will not correct our estimate like from 3 to 5 we can come across situation where product owner can misinterpret more features from team. 11/4/2014 9:49:10 AM

 Hemant Kothiyal Thanks Deepak for your interest in knowing more on my situation.I feels that in my case i will go with story point = 5 for story3, because its same as Mike mentioned in his post that going to third building we have to walk on a very narrow path over a nasty plunge into hot lava below us.Similarly in my case i anticipated that story3 will take more effort that i missed in story1, but i will take care now.Please let me know your thought. 11/4/2014 9:30:45 AM

 Mike Cohn Hi Hemant--You didn't ask about whether you should re-estimate Story 1. And I'm glad about that because you shouldn't in this case. Just live with the minor bad estimate.But, when you later estimate Story 3, I would not compare it to a story that you knew had a bad estimate. I might think, "Oh, this is like Story 1 so let's use that same estimate...oh wait, that was the story that we realized we screwed up and it was bigger. So, let's see Story 3 is also like Story X, let's use that estimate."I'm phrasing it this way because it's unlikely you'd really have a re-estimated valued in mind for Story 1. It sounds like you do in this case but that is probably because you're thinking about it a lot and wondering what to do. In the heat of future sprints on your project, you won't really want to take the time to come up with better estimates for stories like that one.And so, don't compare to a story with a known bad estimate. 11/2/2014 9:59:12 PM

 Mike Cohn Thanks, Anand. 11/2/2014 9:53:27 PM

 Mike Cohn Hi Tony--Thanks. You are right that using points properly requires a mental shift.I've learned something interested from teaching estimating classes at companies and conferences since 2000. Points make no sense at all to someone until something clicks and they make all the sense in the world. It's different from teaching something like user stories. Learning about user stories is like learning to play golf--you can always get better at golf. You can always get better at stories. With estimating, though, the idea of points makes no sense until something clicks mentally and boom! people get it. From 0 to 100% understanding at once but the idea clicks for different people at different times and through different examples. 11/2/2014 9:13:44 PM

 Deepak Joshi Hi Hemant, I am curious to know more about this situation. Could you please tell me on which basis you say that 'Story3 same as Story1? If complexity/risk is known well in advance that there will be risks/complexity same as in story 1 then definitely that can taken into account and dealt with. And if this is being anticipated that there will be risks/complexity may not be same as in story 1, but will definitely will be faced in story 3 then we can provide story points according to that. At least it will help for the estimation of story points up to same extent.Further more at the time of actual task break down it has to be measured in hours.Please bear with me and with lot of my questions. Such practical queries are really helpful for readers. Thanks for bringing up this point.Warm regards,Deepak 11/1/2014 10:49:34 AM

 Hemant Kothiyal Hi Mike,Thanks for nice explaination.On same topic i would like to discuss on one scenario from one of my project.In Iteration1 there was 2 user story i estimated. Story1 - 3point- 25 hoursStory2- 5point- 40 hoursAt the end of the Iteration i found for story1 i took around 42 hours because of some uncertainity, risk and complexity and for story2 around 40 hours.In next sprint planning i found similar story3 same as story1. What should i give estimate here 3 points because it is similar ideal effort as story1 OR Should i estimate it 5 points because i know this is actually going to be more effort equivalent to Story2. 10/29/2014 10:05:41 AM

 Anand Vyas Good one, Mike.It has been a misconception through out that the story points are unit of complexity and not an unit of effort. The example used has very well explained the difference. The complexity is one of the factors that would affect the unit of effort. Effort has always been thought of as number of hours it may take to complete a task. 10/28/2014 12:54:38 AM

 Tony Gibson Excellent point. All too often, people try to make story points fit an exact science or formula. When they can't, they then try to fit it more squarely into a box, be it time, size, or complexity.In reality, it is the aggregate of them all, without being any of them. Points don't represent straight time, because everyone's rates are different. As you rightly explain, we must normalize the time being speaking in generic "units". Points aren't straight size, because it's all relative. A 10 foot basketball hoop is much taller to my kids than it is to me. Even though it is 10 ft, the perception of the distance is key as it relates to the effort required to traverse that distance. And points aren't straight complexity, because that is even more relative than size.It requires a mental shift to throw out the notion of exactness; to embrace the normalization required to agree on the result(generic units of measure) without the necessity to agree on the formula (exact sizes or rates of work). 10/22/2014 1:33:06 PM