Re: [scrumdevelopment] Pair programming and Scrum - Finding the correct balance
A story does not have to be completed at the end of a single pairing
session, it can span multiple pairing sessions involving many
We usually have a story owner ( a developer that usually stays on the
story till it is completed for 0.5-3 days). The story owner's pair
changes frequently at least once a day. Sometimes if the pair feels
confident that she can finish the story, the story owner can go and
pair on a different story as well.
On Wed, Nov 19, 2008 at 2:11 AM, chrisincambo <chrisincambo@...> wrote:
> Hi Guys,
> Now I've found this great list I think you guys are going to be
> hearing a lot from me, so apologies if I bombard the board but I've
> been building this stuff up without an outlet for a while!
> We've been practising pair programming in the office for around a year
> and I still don't think we've found the best balance. Firstly it has
> become apparent to me that the sweet spot for how long two developers
> can pair program together is between 1 and 3 hours and never more than
> half a day. Secondly I have found that in terms of developer
> satisfaction the best way to break stories into tasks is to break each
> story into the smallest complete vertical slices possible and not into
> The problem lies in the fact that these two findings pull in opposite
> directions, usually it is impossible (at least with what we do) to
> think of a vertical slice tasks that takes less than half a day to
> complete. So leaves a dilemma, do we allow pairs to stay together for
> a day or two and retain the vertical slice approach, or do we break
> the task into small sections which usually involves each task
> belonging to one of the layers within the system and keep the pair
> times down to an hour or two.
> The third way is to take a more flexible approach and rather than
> making pair programming a policy, leave it up to developer discretion
> and encourage them to pair when they're working on a challenging
> problem and maybe bring in some kind of peer code review system.
> Any comments or suggestions would be appreciated.