If you are working in a team which practices agile methodology, then you would come across this question. 'what's the best way to estimate user stories?. Is it story points or number of hrs, days? something else?' Let's take an example here to get a better understanding and more informed decision.

Imagine you have 10 people with you, 10 random people all of whom may not be from IT background. You ask them a task, 'Estimate the area of a football (soccer for Americans!) field?". Well, the first thing everyone would try to do, is estimate the length and width of the field. And then they will mentally multiply length x width to the best of their ability.  May be the length is 100 meters and width 50 meters, so 100 x 50 = 5000 square meters? May be it's 130 x 70 or may be 80 x 50 meters? Oh.. wait, we have people who are measuring distance in feets. So it's 300 ft x 150 ft = 45000 square feet? Oh my God, we have such varied answers. So if you take the two extreme of the 10 answers you've got, it may probably vary between 500 square meters to 45000 square feet. This is not helping us here. Ofcourse the correct estimation would be anything that is closest to 7,140 square meters or it's equivalent in acres or square yards or square meters! Your final estimation will be far off from the real world despite spending time and energy in getting an accurate one!

Now lets ask the same 10 people to estimate the area of football field differently. Let's ask them something like 'how many basketball courts make up one football field?'. This makes it much more realistic and meaningful. Humanbeings are good at visualizing something relative to another thing. All 10 people would be able to visualize how large a basketball court is, and therefore will be better at guessing how much more larger, the football field is when compared to a basketball court. No one would be able to tell it accurately but the numbers would be much more realistic and imaginable by everyone else. This is no situation like the first scenario where someone who is comfortable with meters as a unit of measurement did not understand the estimation given in square feets. In the current scenario you are going to get the estimation is same units which is 'basketball courts' and it may range from, say 10 to 25 basketball courts. The correct answer ofcourse is around 17 basketball courts.

Here's a dialogue from the movie Shawshank Redemption. The character Red (Morgan Freeman) says "Andy crawled to freedom through five hundred yards of shit-smelling foulness I can't even imagine.Five hundred yards. The length of five football fields. Just shy of half a mile" When I was watching the movie, the best I could relate to is 'five football fields' to get a measure of how long Andy Dufresne crawled!

Now lets get back to the agile world and user story estimation. Within the team, you will have different set of people with different skills(the same as people who measure length in meters, feet, yards etc). The way they estimate a story in hours could be different and may have a wide range. But instead of estimating in time if you estimate in complexity (Very high, high, medium, low, very low?) then you will get a size of the story. The story point could roughly map to the complexity of the task at hand. A very low complexity could be 1 story point, low = 2 story points, medim = 3, high =5, very high =8 ? If you estimate this way, the estimation numbers from 10 people would not be too wide apart. And story point is a more neutral way of estimation taking into consideration the team instead of an individual. It helps you in arriving at your team's velocity.   

By the way, did you notice that the story point numbers were like 1,2,3,5,8, 13 and not 1,2,3,4,5,6. In otherwords its fiboanacii numbers. Why fibonacci? Lets justify that with an example.

Let's give weighing stones each weighing 1kg, 2kg, 3kg, 4kg and 5kg to 10 people. The stones have no markings on them, so you couldn't tell which one is 1 kg, which one is 2 kg etc. Lets ask the people to identify the stones correctly. If you give someone a 1kg and 2kg stone, they would be able to clearly tell which one is which. Because the difference in weight is 100%. Now give them a 4kg stone and a 5 kg stone. It's more likely that half of the people will identify them wrongly. Because the difference between two stones is only 20-25%. Now give them a 3kg and 5kg stone. It's more likely that all will identify the stones correctly, because the difference is nearly 60%. You see the point?

The fibonacci series is arranged in such a way that each number is approx 60% more than the previous number. By following story point estimation technique in fibonacci series, teams will arrive at consensus on estimation faster. And with story point estimation with fibonacii numbers, if you get conflict, it will be to a wide degree i.e someone saying the estimation is 2 story point and another saying 8. You can then discuss more effectively when compared to discussing a story where one says 10 hrs and other 13 hrs. With fibonacci series, different people in the team are more likely to agree an estimation to be 8 story points or 13 story points, instead  of 10hrs or 13hrs. Agree?

It is fair to say that no estimation methodology is 100% accurate. But if the scrum teams follow story point method for estimation, it is likely to get to a point where estimations are more closer to the actual efforts spent.

It is very difficult to convert a story point to a time estimate. It should not be tried. But if you practice and get better at this, your teams will be able to get a conversion formula over a period time. 1 SP = 2 hrs, may be 4? You will know it!