Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

If it was a 2-point story for one person, would you double it if people are pairing?

Pairing isn't always necessarily done 100% of a dev task, so it seems that doubling the story points seems wrong. And it might not be obvious how much of the task will require pairing until the end, so you wouldn't know what the points the story should be until you've finished - and it seems strange to change an estimate midway through a sprint.

However, if velocity is going to be an accurate representation of how much work we can get through during a sprint, it seems right to change the estimates if more than one person is working on a task. But also, this seems like it adds a lot of admin overhead.

Thoughts?

share|improve this question
1  
By suggesting that perhaps the sizing should be increased for a paired story, you seem to make the implicit assumption that pairing will slow you down compared to going it alone, or that adding an additional person reduces overall capacity. What's the evidence for that? –  JasonTrue Aug 22 '13 at 23:43
    
Based on comments from the devs. It seems the general consensus from them is that it's not always as productive as two people working on two tasks and catch up frequently, rather than one person sitting there watching. My gut feel was that a 2-point story is a 2-point story, but it was something they raised I wanted to see what other people thought, to validate my gut feel! –  Ani Møller Aug 23 '13 at 0:57
    
@JasonTrue: In my experience pairing does slow down in general. Of course, it has the advantage that knowledge about the code is spread among the developers. So, you have an advantage and you have to pay a cost for it. –  Giorgio Aug 23 '13 at 3:41
    
In my experience, pairing removes gumption traps and increases velocity on complex problems. I've only found it to slow me down on trivial problems. –  JasonTrue Aug 23 '13 at 4:16
2  
Developers often raise this issue in environments where story points and velocity are being misapplied as an individual performance metric instead of measuring project variance. You might want to re-evaluate the perception of these numbers within the team and the outside organization. –  CodeGnome Sep 2 '13 at 18:33
show 3 more comments

4 Answers

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
Yep, that's what I said, too. :) –  Eric King Sep 5 '13 at 15:11
    
It was good to prove what I read on the internet can sometimes be right! :) –  Ani Møller Sep 5 '13 at 21:39
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.