Story Points are units of relative size used in estimating software requirements. This is an alternative measurement to time based analysis. Points are estimated by assessing complexity rather than duration. Story points work in conjunction with User Stories.
What are they good for?
Story points are a fantastic way to estimate how long it will take to finish a product. They replace the standard time-based estimate with a more detached concept. Story Point is not the only vernacular around to describe this measurement. Some XP teams also call them cheezits or acorns.
We use story points when estimating for the long term, for instance against the entire product backlog. It's not a good idea to use them in planning for a particular sprint, as sprint velocity will vary.
Good quote from Mike Cohn on Velocity,
"This is why I say velocity is a useful long-term predictor but is not a useful short-term predictor.
Velocity will bounce around from sprint to sprint. That’s why I want teams to plan their sprints by looking at the product backlog, selecting the one most important thing they could do, breaking that product backlog item / user story into tasks and estimating the tasks, asking themselves if they can commit to delivering the product backlog item, and then repeating until they are full. No discussion of story points. No discussion of velocity. It’s just about commitment and we decide how much we can commit to by breaking product backlog items into tasks and estimating each. This is called commitment-driven sprint planning."