Loading ...
Sorry, an error occurred while loading the content.
 

Re: [scrumdevelopment] Pair programming and Scrum - Finding the correct balance

Expand Messages
  • Cenk Çivici
    Hi, A story does not have to be completed at the end of a single pairing session, it can span multiple pairing sessions involving many developers.. We usually
    Message 1 of 5 , Nov 19, 2008
      Hi,

      A story does not have to be completed at the end of a single pairing
      session, it can span multiple pairing sessions involving many
      developers..

      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.

      Cheers,
      Cenk


      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
      > layers.
      >
      > 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.
      >
      > Regards,
      >
      > Chris
      >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.