Story points are a representation of the effort required to implement a story. Point estimations mostly depend on the perceived complexity and uncertainty.
A very common mistake is to try to map story points to hours. The main reason this is a mistake is that we are not good at estimating hours in the first place, so this kind of mapping would mean that our points estimates are at least as bad.
The second is that if you try to map how long it takes your team to complete one story point, you will get a normal distribution, not a linear one.
We are bad at estimating in hours
It's no secret, humans in general are just bad at estimating time, it has been proved in the past. Software development is no exception.
The problem with hour estimations is that they are absolute measures and they do not account for everyone's perception of the complexity, the uncertainty or the fact that each teammate has a different speed.
The relationship between story points and hours
As Mike Cohn points out in this post, the relationship between story points and hours is not linear.
Put simply, this means you would be able to say: 1 story point usually takes our team 1 to 7 hours to complete.
However, you would not be able to say: 1 story point takes us 4 hours to complete. This kind of logic would assume that throwing more developers at the problems will fix the problems faster and we all know better. Again, this is simply because we are not taking into account each developer's perception of the required effort, complexity and uncertainty.
A relative approach works best
In the end, what we really want is an estimation of the amount of work we can deliver periodically as a team. Since story points are an abstraction that encapsulates the effort, the complexity and the uncertainty that each member perceives, it is a relative value that can be used to better predict the future.
Estimating the first story will set the whole thing in motion. Let's look simplified example that demonstrates why relative estimations are better than absolute ones.
If I estimate that it would take me 6 hours to complete the first story while a faster developer says it would take him 2 hours, we will never agree on a correct estimation for a specific story.
However, we can just both agree that this story is worth 1 point. The next time I think a story should take me 12 hours, I can refer to that first story and say it's a 2 points for me. The faster developer would agree with me because, in his mind, 2 points is 4 hours.
Estimating with points is also helpful for the product owner because he is able to look at past velocity to assemble a release roadmap that he can adjust over time.
In Pivotal Tracker, there is no direct way of estimating in hours and I think it's an excellent approach. At first Tracker may seem restrictive, but when you dig deeper, most of those restrictions are actually intentional ways of enforcing good Scrum practices.