Pick up most any book on agile or Scrum and see what it says about planning a product backlog or planning a release or about computing an end date for a project. It will say to identify the stories, estimate them in points, add up all the points, and compare the backlog point total with your velocity to figure out how many sprints it will take to implement all those stories. Then reserve some room for unknowns and for changes (agility).
So, that implies identifying and estimating stories far enough in advance to match whatever your planning and commitment horizon is. This implies that estimating story points in sprint planning or just before sprint planning or even one sprint in advance is likely not far enough in advance unless you are ultra-agile and aren't making commitments or setting date expectations more than a couple weeks out.
Most companies I work with have a planning horizon that is 3 to 6 months out. So, we put together a 4 or 6 month plan. That plan is going to be based on what we can know in advance, namely, user stories. (Sometimes we do this at the feature level, but that's another blog post.) We won't know research stories or spikes or defects or production support in advance. Whatever goes into the plan is what should go into the velocity metric. Stated differently, you shouldn't put anything into your velocity metric that you can't plan for 4 to 6 months in advance. Which means you shouldn't bother putting points on defect or on research stories. If you are going to compare apples to apples, your velocity must exclude unplannable stuff.
That's why I put points only on real user stories. Here is a series of blog posts I did on each of these topics:
Now, some people try to estimate this unplannable stuff. They try to quantify it in points and include it in placeholders in their plan. You absolutely should track this unplannable stuff, and you should reason about whether it will be more or less in the future, but trying to back it into points or plan it using points is folly.
