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

The problems with Agile estimation, story points and velocity.

Is it a fallacy? You have a base story to come up with story points for another story
Michael Cohn mentions one story where on a team there is a 7 year old kid and a brain surgeon. There are 2 stories to estimate. One lick 1000 stamps and one to perform surgery. He mentions these two should be the same amount of time and thus the same amount of story points and the ideal person should work on it (obviously the brain surgeon). He glossed over this part of the story though. How did the boy come up with the estimate for brain surgery, when he probably couldn’t estimate even the time to lick 1000 stamps? Ok you say that’s because they didn’t have a base story…. Ok fine. They have a base story of milking a cow. From the milking a cow time of 1 point can you figure out how much different the licking the stamps or the brain surgery is? I can’t. I doubt you can either unless perhaps if you milked a cow and licked a lot of stamps before.

Ah so its easier if I did the exact thing before… yes… I don’t know about you but the stories in our backlog are pretty close to the above story. Story #1 develop a powershell script to deploy code (no one on the team knows powershell), Story #2 Implement a windows service, Story #3 Add an item to a web page. I don’t know about you but if I don’t know the language, I don’t know how long it will take me to do something… I can guess the time to learn… but I don’t know how to compare it to these other stories. So comparisons don’t help unless your stories are similar enough that you can compare them… our backlog is a jumble of things I can’t compare but I probably can estimate some of them, but sometimes not even that.

The team can estimate a story
As we saw in the story above Michael Cohn mentions with the boy and the surgeon it is unlikely the boy could have provided an estimate for the stamps and definitely not the surgery. So how could you estimate? You would need the expert to estimate, the brain surgeon. This I think is similar to a lot of stories in developer backlogs where different technology is used which one developer may know and the rest do not. So should the other developers participate in estimating story points when they can’t compare and don’t really know enough? I saw often on Agile teams I see the equivalent of 6 boys and girls who know nothing about brain surgery estimating something akin to brain surgery.. ok maybe not quite but you get the picture. One example is a manual QA testers estimating stories with developers. The QA person knows little about what the developer needs to do, and the developer maybe some of what the QA person needs to do. Yet they both throw out numbers trying to estimate the whole story even though each may know only half or less. Is that fair if one estimates low but the cost is high for the other, and even after explanation they just meet in the middle because they don’t understand each other’s world. Wouldn’t it be better instead to have QA estimate their part and Development estimate their part. Then they at least have a fighting chance at understanding what they are estimating.
Using velocity and story points we can calculate if we can complete by a date with fixed scope/resources.

Imagine you have 10 team members. You have 10 stories. Story # 1 is 91 points and stories 2-10 add up to 9 points. Your teams velocity is 100 per sprint and it’s a 2 week sprint. So by that calculation your team will be done in about 2 weeks. There is one catch. Story #1 can only be worked on by developer #1 even if it’s split up because its in a different tech stack and a foreign language Japanese.
So now how long will it take to complete? I guess we’d have to calculate the developers individual velocity (though most Agile shops don’t calculate that… ok let’s say it was about 10 story points anyway). So that would be about 9 sprints or 18 weeks. That’s a pretty big difference from the first average estimate with just velocity.
So the only way we might have seen this is perhaps creating a sprint iteration plan that might have made this more obvious… but a lot of shops don’t do that I think? This gets even more complicated when there are dependencies as the best tools to visualize time and dependencies are things with gant charts like MS project that like things such as time for each task/story rather than story points.
Sure you can try to convert but unless your team has a stable velocity that gets tricky because you can be way off. But if you don’t either do that or lay all of the dependencies out manually on an iteration plan your schedule might be way off. Does it seem story points are making this more complicated that it needs to be? Partly this seems because Agile wasn’t designed to work well on fixed time/date/scope projects since Agile estimates are a little more wishy washy and relies on stakeholders being collaborative rather than holding fast on time/date/resources. You think this doesn’t happen? It does even in Agile shops, and then those estimates get to be really important to know when you really can deliver and it seems the Agile story points/velocity might make this a little harder in this scenario than if we had just used ideal days, proper dependencies/project plan to analyze them along with resource constraints.

So the summary suggestions would be
- Developers should estimate developer tasks they know and just the dev portion of the story
- QA should estimate the QA tasks they know and just their part of the story
- Sometimes its just easier to switch to ideal days.
- Its ok to say you don’t know how to estimate a story and if you don’t know the tech maybe you shouldn’t be estimating
- Use dependencies and a proper plan if your project is complex
- Don’t forget resource constraints can block your project so either create iteration plans or even full project plans to help identify
- Sometimes its hard to compare stories to get story points when they are really different or new tech, so again ideal days may be easier
6/9/2016 8:43:14 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. " --

I 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

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:

4/10/2015 11:48:27 AM

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.

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

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

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 hours
Story2- 5point- 40 hours

At 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

To leave a comment, please login with your credentials.


Newsletter Sign-Up