The estimation using story points is a relative sizing, so you can usually refer to the smallest or the easiest user story to be estimated as a reference story, then you relatively size the other stories. The scale used for the story points is exponential scale (such as Fibonacci sequence) to encourage team restricting their estimates to lower ranges. If we pick up large numbers on the scale, this implies high level of uncertainty and indicates that those user stories are very big (Epics), so we have to break them down to refine their estimates and lower the uncertainty.
Relative sizing of the stories makes the estimation process easier and faster, usually team can reach consensus quickly. The story points represent the estimated effort to be done by the team to accomplish the related user stories, this will help the product owner calculating or evaluating the ROI (Return on Investment) of the user stories and this can be done by using the following equation: R.O.I = Business Value / Effort (Story Points), so the product owner will be able to prioritize the user stories in the backlog based on a clear inputs, either from the business or the technical perspective.
Mistakenly people mix between user points and tasks estimation, We use the user points to estimate stories at the release planning level. It will be just enough to use story points at this level of planning. Later on at the iteration planning level, we start estimating the concrete tasks required to fulfill the user stories of the current iteration. At iteration level, the tasks estimation will be hourly based.
We usually use Fibonacci series (0, 1, 2, 3, 5, 8, 13, 20, 40, 100) to assign points to the user stories. As mentioned before, user stories should be small enough to be estimated in the lower range of the series (something like 0, 1 , 2, 3, 5, 8, 13). If we found that our user story weighs 20, 40, or 100, this indicates the user story is big (Epic) and not sliced well, and the uncertainty space around it still big.