The way I understand it, a story-point is an estimate of relative effort, not man-hours. The effort required of a story isn’t going to change just because a pair is working on it, so it doesn’t make sense for the story points to change…

Also, velocity is derived from the history of what got done in the previous sprint(s). If you pair on some stories and not on others, over time the average velocity will reflect your average sprint capacity, automatically taking into account your team’s pairing habits. There’s no need to manually adjust sprint estimates based on how much you think you’re going to pair on certain tasks next sprint.

Indeed, it’s these manual tinkerings that most often cause scrum efforts to be derailed, because nobody trusts the ‘estimates’ anymore, due to all of the ‘gaming’ of the numbers.

TL;DR

Story points are estimates of the effort for the team as a whole to move a story from “started” to the “definition of done.” If stories don’t involve multiple skill sets or involve multiple people, you probably have a task rather than a story.

Story Points Aren’t Man-Hour Estimates

Story points are a measure of relative effort:

  If FOO is a baseline 2-point story
 And BAR is roughly twice as much work
Then BAR is a 3-point or 5-point story.

In Scrum, one typically sees the Product Backlog estimated in story points, although opinion is often divided about whether individual tasks should be estimated on the Sprint Backlog. When estimating Sprint Backlog tasks, one can certainly use ideal hours rather than story points, but even so the estimates are generally for wall-clock time rather than man-hours.

Scrum Teams Use Self-Organized Time-Boxes

Man-hour estimates are usually a “project smell” that a team is not fully self-organizing. An effective Scrum team is agile precisely because it enables teams to shift resources from task to task as needed within each sprint.

If the team embraces pair programming, or if a story requires multiple team members to swarm over specific tasks, then the team should be factoring those things into both their story-point estimates and into their Sprint Planning. During Sprint Planning, the Scrum team peels each story off the Product Backlog, estimates it, and then tries to determine if the story will fit into the current sprint.

Team effort required to reach the “definition of done” tends to be a more accurate tool for this type of assessment than measuring man-hours. However, the team should use whatever metrics lead to the most success for the project.

Generally speaking, the key is to let the task performers (e.g. the development team) do the estimation. Man-hour estimates tend to be a budgeting tool imposed on the team’s estimation process from outside, rather than providing an effective estimation technique for a time-boxed process. Scrum is based on time-boxing, not the 100% utilization fallacy, so it’s probably best to avoid techniques designed to measure utilization right from the start.

Each team and each project are different, so your mileage may certainly vary.

As already stated in the another answer, stories are usually estimated in relative sizes. Therefore it shouldn’t make any difference.

Maybe the fact you think you need to pair specific stories shows that they’re a different level of complexity compared to the others and should consider putting more effort into their estimation.

Your team seem unconvinced by the value of pair programming – as you say in the comments. You should think about how you’d change that. Consider doing a trial of exclusively using pair programming and one without. Of course, it won’t be conclusive but it should help your team gain a better understanding.

I find TDD really helps facilitate pair programming. The method of coming up with a test first helps the pair easily decide on their goal.

I found not pair programming (with TDD) was a false economy. We had a faster velocity until a build up of hidden bugs caused us to break down and deliver nothing because of a need to fix bugs.

When we pair programmed, our velocity was 15% slower but then at the end of each release, we had completely eliminated a class of bug. It was more predictable.

Doing pair programming with TDD requires discipline. And we all know being disciplined is hard and your team might not want to be but then you have to convince them.

To follow up on this….

I met with a scrum consultant last week and asked this very question of him – his response was that it shouldn’t change the way you estimate story points. If you do pair programming on one story, the expectation is you are doing a level of pair programming on many/all stories, so any over/unders in manhours effort should even out over time, and shouldn’t affect velocity.