I was recently emailed a question asking whether the sprint planning meeting should start with time allocated for putting story point estimates on any user stories that have not yet been estimated. No, I don't think this is a good idea. Keep in mind that we put estimates on product backlog items (which I recommend be user stories) so that:

• the product backlog can be prioritized. It is impossible to fully prioritize a set of items without knowing at least their relative cost.
• we can make high-level forecasts about how much will be done by when
• we can make tradeoff decisions between scope and schedule

We can achieve these goals with approximate, relative estimates such as given by story points. For example, if I decide to buy a new car this weekend it is sufficient for me to know that I can get a Toyota or Honda for around $30,000 and that a Ferrari goes for closer to $800,000. I do not need to know a more precise cost of the Honda ($31,850) before knowing it should be on my short list of cars to evaluate while the Ferrari should not. Sprint planning meetings typically go into deeper detail than is appropriate for product backlog item estimating (whether in story points or ideal days). Since we become accustomed during sprint planning to breaking user stories into tasks and considering those tasks in more detail, there is a chance this will carry over into any story point estimating done during the same meeting. So, when should story point estimating happen? I'll describe the ideal case, which you can easily adjust for the real-world intrusions on your project. Projects typically start in either of two ways:

1. A reasonably fully stocked product backlog is written before the first sprint begins and all items are estimated before the first sprint planning meeting. [If you do this, be careful not to write all user stories with too much detail. Each product backlog item you write represents an investment. User stories should therefore be elaborated just-in-time and in just-enough detail that they can be turned into functionality in one sprint.]
2. We know we've got to do the project so we dive in. During the first sprint or two, all the user stories are written and estimated just like above.

On an ongoing basis, once per sprint I recommend that the ScrumMaster tell the team something like, "Hey, we've had five new user stories come in this sprint and we need to estimate them. Everyone plan on hanging around for a bit after tomorrow's daily scrum meeting and we'll play Planning Poker to estimate the new items." Doing it right after the daily scrum helps cut down on the number of interruptions in total. I usually aim for having that meeting about two days before the end of the sprint. That way the product owner will have estimates on them so she can prioritize prior to the start of the sprint.