Taken from https://www.mountaingoatsoftware.com/blog/its-effort-not-complexity
Complexity is a factor in the number of points a product backlog item should be given. But it is not the only factor. The amount of work to be done is a factor. So, too, are risk and uncertainty.
Taken together these represent the effort involved to develop the product backlog item.
Story points are an estimate of the effort involved in doing something. That estimate should be based on a number of factors, including the volume of work, the risk or uncertainty inherent in the work, and the complexity of the work.
"Story Points are a measure of how long it will take (effort). How long it will take can be affected by other things and those can influence our estimate. The key is to remember and understand that it is always about time--no client ever cares how hard we had to think, only how long it took." -- Mike Cohn
"Story Points are just another way of estimating effort. Other things can affect that estimate to the extent they effect effort. But points are about effort. [...] One of the most compelling reasons to prefer story points even though it is another way of estimating effort is because it allows individuals of different skills to discuss the relative size of work." -- Mike Cohn
"Yes, in Agile Estimating and Planning I wrote about the points being about how "big" the story is. I wasn't as clear in there as I have been in this post. It is all about the amount of time something will take. No client / customer / stakeholder cares about complexity except to the extent that complexity affects my estimate of effort." -- Mike Cohn
"Let's say that Story Points measure complexity... My question would be: then what? So they measure complexity. How is that useful to the business? How does it help make predictions or do release planning? The beauty of relative effort estimates is they eventually map directly to time, and to cost. We can very soon make realistic date and cost estimates based on empirical data. I can't see how you can do that if you are estimating complexity.
Of course, the ultimate goal is to have all stories approximately the same (small) size, i.e. take approximately the same time to develop, so we don't need to estimate them. Velocity then simply becomes a count of stories completed per sprint.
Pretty much all software development is complex, singling out certain stories as "more complex" may trigger some good dialog, but is unlikely to be helpful to the business." -- Tobias Mayer