Goal
It’s goals is helping the product owner and team to prioritize work and make user stories clear for all team members.

Notes

• Story points estimation is just an estimate not a blood-oath. So there’s no requirement to work weekends in order to compensate for under-estimating a piece of work.
• Story points estimation is a team sport. Involving everyone (developers, designers, testers, deployers, product owners… everyone) on the team is key.
• When estimation is above 20 points, the user story should be broken down into granular pieces.
• Learn from past estimates. During retrospectives take some user stories with the same estimation e.g. 8 points en discuss whether each of those work items had a similar level of effort.
• Story points reward team members for solving problems based on difficulty, not time spent. This keeps team members focused on shipping value, not spending time.
• Story points shouldn’t translate to hours or any other measure of time.
  That said it is also a mistake to only take complexity into account,
  because for a product owner and team to prioritize work, we have to take into account the whole effort to get the user story available in production for the user.
  A simple refactoring, could result into many regression testing or a deployment change.
• Story points are relative. They only have a meaning when compared to each other.
• Story points estimation should facilitate discussion, to discover unclear requirements.
• Story points estimation is not a requirement in Agile or Scrum, but is has some key advantages.

Why Are Story Points Better Than Hours?
Estimating the number of hours for a task has one big problem.
Different engineers will take different amounts of time to complete the same task,
due to differences in their experience, knowledge, and skill.

However, the user story’s complexity relative to other user story’s would stay the same, regardless of the difference in developer skill.

Sources:

https://www.atlassian.com/agile/project-management/estimation