I think Frank's and Encaita's answers pretty much covers it but there are some additional things to consider:
Why use story points
The aim of estimating with story points is to give the relative complexity of developing features for your application. A simple way to think about it is take a story you have in the upcoming sprint e.g. a url change. You know this is simple in terms of complexity, and has clearly defined acceptance criteria so the whole team agrees that even with testing it's a 1 (using the Fibo scale).
The next story to be estimated is aggregating a set of user data and visualising that on the front end. Now as a developer you know immediately this is way more complex than changing a url. You discuss the story and the acceptance criteria and you have a lot of questions and can see several potential solutions for doing this. The other devs and QA also agree it's very complex. So you all agree that it's a 34 point story. It's worth noting that the Fibo scale also allows you to indicate how much confidence you have in the esimate - the bigger the gaps between numbers indicates the less confidence you have in your estimate
At this point your Scrum master should jump and say that this as a single story is too big and needs to be broken down into smaller stories of less complexity. You can approach this by doing what are known as SPIKES - this is just some time set aside to investigate something. So for this example you and the other devs agree you want 4 hours to discuss and investigate the possible technical solutions.
To cut a long story short you break that big story up into four other stories of 5, 8, 8 and 13 points. No remember that these estimates are all about relative complexity - they don't have to add up to the original estimate plus you have more information now to make a more accurate estimate.
You then agree as a team that for this sprint you'll aim to get done the 13 point story, one 8 point story plus the 1 point url change you had already identified. So a total of 22 points. The next sprint you get 27 points done, the following sprint you get 18 points done. After 3 sprints you can start to get some confidence in your velocity (velocity is the amount of work your team can get done in one sprint). To get the velocity take the average of the previous sprints. So in this example the average is (22+27+18) / 3 = 22.3 so round it to the nearest on the Fibo scale which is 21.
Now for the next sprint just aim to get 21 points done.
Don't get hung up on getting your story point estimate exactly right - it's not an exact science. You know a url change is far less complex than aggregating data so just score it accordingly.
Plus discussing these things as a team is good. Look back at your estimates during sprint review and discuss if you were happy with them or not and then feed this into the next sprint planning session.
The whole team estimate
The whole team must agree on a single estimate for each story. A feature isn't done until it's production ready. Just getting the code written is by no means done. In my experience Scrum teams have been far more effective when working as a team. Take an example of the team I'm working with right now. When I joined they were doing all the sprint meetings and planning poker but during the sprint the process was 1. BAs/Product Owners define the requirements as stories with acceptance criteria and acceptance tests 2. They hand these requirements to the developer who then writes the code 3. The developer has the code merged into the development branch for QA to test 4. QA test then they start asking questions and tests fail so it goes back into development.
What's missing here? There's not enough discussion up front and each team member only saw their own task. Now the BA/PO, devs and QA get together before writing any code to discuss the requirements in detail and ask questions up front, then continue the discussion throughout the sprint. This is far more efficient and leads to better quality solutions.
Planning poker helps this process because it forces the team to discuss the feature and agree, as a team, how complex delivery of that feature is. In traditional software development the Project Manager was responsible for delivery of the project but anyone with experience of that approach knows it doesn't work because more often than not, people do not take responsiblity for their part in the delivery of the application. In Agile you shouldn't need project managers because the team takes responsibility as a whole for delivery of the application.
On time estimation of tasks
My view having worked with teams that estimate time on tasks and teams that only do story point esimtates is DON'T DO TIME ESTIMATES! They're actually just a waste of time. They're not as accurate as story points because they are specific to individuals not the team, and each individual will have a different idea of time estimation(bring on the flame).
Story points accept that things i.e. requirements, change all the time so really you need an indicator of what the team can complete in a sprint.
Once you have an understanding of velocity you can measure your deliverables in time because you know what you can get done in each sprint e.g. every two weeks you know what features can be delivered. Your scrum master and product owners should be having estimation sessions to look ahead to future sprints then you can get an indicator of how much work you'll get done in the coming few months. This allows product owners to make prioritisation decisions about what features to include in the final application.
I've had developers ask that we estimate time for tasks in order to plan but I actually disagree with this approach (in fact I strongly disagree with this approach) because it is not accurate e.g. what does this will take me 4 hours really mean: one dev might include only the time on the task itself, someone else might add time for making cups of tea!
Time estimates are always handed to someone else for reporting purposes and it also overemphasises the individual elements of delivering a feature vs the whole team effort.
Estimation isn't the biggest problem
As an aside, figuring out estimation is not the biggest problem I think teams have to solve. The most important thing is working together as a team to get things done throughout the sprint, so that you don't hand everything over for testing on the last day. You want to see a steady trickle of features throughout the 2 week sprint. The team dynamic I explained above is a large part of this. Story point estimation will help you plan for this because you'll see which are the big stories that need breaking down into smaller ones that can be delivered into testing regularly.