Story Points Calculations

If you start mapping story points directly to hours, you may as well just use hours, because it is less complex. There is a lot of benefit in keeping estimation simple.

One good reason not to use hours is that one team member may take longer than another. Using story points, a team could, for instance, estimate using a combination of risk, uncertainty, complexity and effort for the entire team.

I think most teams use fibonacci numbers. But there is no rule about this. It's up to the team.

Assuming the team do use fibonacci numbers, the simplest way to start could be to pick a relatively small piece of work, and assign it as 2 points.

The team can use this as a benchmark. If something is roughly half the size, they may estimate it at 1 point. If something is approximately 1.5 times the size, it may be 3 points. If it's approximately 2.5 times the size, it may be 5 points.

It's important to remember that these are estimates, and the most valuable impact of estimating is to help the team plan, forecast, identify misunderstandings, and negotiate scope. Chasing 100% precision is wasteful, and teams should be careful that they don't spend an unhelpful amount of time and energy making their estimates better than they need to be.

Once a team has a reasonable understanding of what a story point is, the benchmark measurement of 2 points can probably be forgotten.

I know we have different way like below but I want to how can I know exactly how much efforts a developer giving on a particular story in Hours point of view.

The purpose of estimation is to help a Development Team figure out how much work it reckons it can take on during a Sprint. There is no need for any greater exactitude. Effort and complexity may be taken into consideration as well as time.

Also, note that the Development Team is responsible for making any estimates, not the individual developer whose opinion may be sought in order to reach a consensus.

You have 2 different things going here.  Estimation of stories and your desire to "want to how can I know exactly how much efforts a developer giving on a particular story in Hours point of view".  By definition an estimate is not exact. 

Mike Cohn (www.mountaingoatsoftware.com) used an illustration in a class I attended recently when he was discussing estimation. He gets full credit for this. I'm going to modify it slightly because he used pictures and I can't.  Consider that you have 2 people that want to walk the distance of 100 yards and both of them estimate it is a "2".  Then when asked to estimate walking 50 yards, the say it is a "1" because it is half the effort.  Now a 3rd person joins who is on crutches.  Is it a higher estimate for that person?  Not really.  Walking 100 yards is still twice of that to walk 50 yards.  If you try to do this based on time, all 3 of the individuals could have different estimates.  And actuals are most likely to be even more varied. 

Estimates should not be equated to actuals.  You have to track those separately.  You can use actuals to help individuals start to refine their estimation abilities but they are completely different things. 

Taking from another article I read by Mr. Cohn, estimation at the story level should be done in points so that we know what to work on compared to other stories.

Estimating at the task level lets us know when we'll be done.  We track stories on a binary basis, we are either done or we're not.  But tracking at the task level is more about how much work do we have left to do.

Tasks are supposed to be 1 day or less, but if we are tracking time spent and constantly reestimating time left to complete, we'll improve our estimations and our story pointing skills at the same time.