The planning of a scrum sprint has two components.
On the one hand, you estimate the complexity of the stories and tasks on the backlog in the unit of Story Points. More on that later.
On the other hand, you how many story points the team can deliver in one sprint. This is called the velocity and it is based on the historical data of how many story points the team delivered in the previous sprints. Here, you can also factor in things like known absences, due to, for example, (public) holidays.
Story Points are a relative measure indicating how much effort a given task will need when compared to the other tasks in the project. The first few times you may need to designate a simple (but non-trivial) task as 'reference task' and define 1 Story Point as being the effort needed to complete that task, but after a while people will start saying: "Hey, this task/story looks similar to that one we did two sprints ago. It should have the same number of Story Points."
You should be aware of the risk of Story Point inflation. This is a risk with people who are used to estimate effort in manhours and it happens when they start giving consistently higher estimates than before, because previously they forgot to factor something in (for example, testing). If you consistently forget to factor something in in your Story Point estimates, then you should not adapt your estimates because the fact that you consistently forgot something will express itself in the velocity of the team, so adapting your estimates results in a double compensation.
And for managers especially, it is folly to think you can compare Story Points from different teams. If you have multiple teams working on a project, it is very well possible that their velocities differ by as much as a factor 3, but that the team with the lowest velocity number produces the most value, just because their unit of measurement (the Story Point) is so much bigger.