Story Points deserve more than a short blogging post to have all techniques and pros and cons considered. Nonetheless, I think I can make a case for something short and sweet on this subject.
Story points are not required in Scrum. They are a tool that can be used despite the framework of Agility a team or a company is preaching. They are a tool for estimating. They are not a tool for estimating time. Story points are a measure of relative complexity. Let's break this down.
Story Points are relative
Story points do not talk about how long does it take for a feature to be completed. It does not translate in time. It is not the same for all teams, for all subjects. It is just a helper on understanding the complexity of a task. 20 story points for a team can be a full set of features and for another team can be the work of a sprint.
Story Points support the understanding of User Stories, and together are a common knowledge on the Agile community, notably Scrum. The consensus is that complexity of things can grow exponentially, so Fibonacci sequence, being a great way of mathematically modelling a lot of complex things in life, was a natural choice.
Fibonacci grows as in 1, 2, 3, 5, 8... and beyond. Some people, for the purpose of Scrum planning, like to add 0 and the 1/2 estimates for fine grained outlook. I particularly think this is overkill. Regardless, whenever used, those Fibonacci numbers should be understood as in 2 is more complex than 1, 3 is more complex than 2 and over time you see that the complexity can grow fast, with items becoming 3 or 4 times more complex than the previous one and become impossible to handle. That is why people like to look at 1 and 2 as easier tasks or stories, 5 and 8 as moderate, 13 as fairly complex and maybe not even addressable and beyond that it is just wild speculation. Even if you use different values, the idea is still the same: the bigger the number, the more complexity we have. As complexity grows, clarity might suffer. Without clarity one might not know if a task is finished or if results are correct.
That is why people break stories down and try to keep complexity at bay. If someone says a certain part of a feature is a 13 complexity the team must come together and understand all the facets of the problem, because that number indicates there are unknowns. In Planning Poker teams can go even further showing the "?" wildcard to be extra clear about their lack of understanding of the feature.
As an example, when a team says creating a shopping cart is a 13 and a user registration is a 5, the team signals they understand the user registration better than the shopping cart as in actionable steps. It means they have not much of a problem sitting down and cooking that feature, as opposed to the shopping cart, that seems too much of a work, hidden or otherwise. Question such as "Is my shopping cart just accumulating items followed by a checkout button or are we talking about being able to apply discounts, move items in the cart, change quantities and more?", certainly put the Product Owner in check so she can be more precise in her view for that feature. She might mean the fully fledged Amazon.com cart or she might just mean a very simple item accumulator. She is called to explain. The team learns. It might make sense to choose the more complex shopping cart, but starting with the simple accumulator. One user story just became two or three more, in an incremental progress. The complex story of the full-blown shopping cart 13 is now 3 stories of respective complexities of 5, 5 and 3. It can get more complex as more details are thought off, but hopefully it get simpler for everybody as far as the next step or story is decided. Clarified. The team can move on.
Story Points express complexity
One of the biggest problems I see with teams adopting user stories as their measurement of complexity is when they do or are forced to do man/days estimation. They are nor the same thing, cannot be the same thing. They do not translate. It is not the same unit of measurement by any means. And yet, most conventional (and even some unconventional) companies try and translate them in any possible way, only to end-up frustrated with the math and results.
Volume, as per the metric system, is measured in liters. Mass in kilograms. 1kg of flour is the same as 1kg of water, but the volume they occupy is different. 1kg of water yield 1L, whereas the same amount of flour occupies almost twice that space in volume. Just go chekc in your kitchen. You can also try and backpack with your amazing Deuter 60L only to discover you can barely move if you put the equivalent of 60kg in it, even if it fits the volume with positive ease.
Complexity and duration are the same problem. We can have simple tasks that are just long (because of process or algorithm) and complex tasks that are actually fast (just risky). You cannot guarantee a 5 story points will take less time than a 8 story points. You cannot guarantee even a 3 will be faster than a 8. Some people will argue that in such cases you did not estimate your complexity correctly, but I reserve my right to disagree. Finding an integral of a function is complex but can be actually faster than certain operations such as square root and multiplication, which one cannot say is more complex. It all depends on the parameters given. A great example of something simple that lasts forever is finding PI, or a circle's circumference divided by its diameter. It is so simple it even has a formula:
C= π*d = 2*π*r
Go try and find the full number. Even computers are still trying to reach the final decimal digit. So, simple does not mean fast. Simple does not mean anything other than not difficult according to one's knowledge.
Yet many people get frustrated when they math of complexity times a factor yields so many man/days in estimates only to be blown up in the actual duration of a task. Ah, the traditional need to estimate days of something.
Estimates deserve a long discussion on its own, but the takeaway of this post is to use your tool according to its intention. Story points help you to identify risk and unknown in the scope. It helps in refining the backlog. It works in a way like the 5 Why's. Mitigate risk by reducing complexity, by bringing clarity to your team. The smaller the number, the close the team is to understanding and delivering. And that is all.