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

RE: [scrumdevelopment] Re: End of Sprint problem

Expand Messages
  • Steven Gordon
    If you could reduce your sprints to 2 weeks (by attempting to do proportionally less), then you could just put non-critical bugs on the backlog. Then every
    Message 1 of 6 , Dec 16, 2003
    • 0 Attachment
      If you could reduce your sprints to 2 weeks (by attempting to do proportionally less), then you could just put non-critical bugs on the backlog.  Then every two weeks, the customer can make the decision for the coming sprint as to which non-critical bugs are worth fixing now vs. which bug fixes are of less value than some new features. 
       
      The latency on non-critical bug fixes would be 4 weeks, which is no longer than it is under the leaky 5-week sprints.  This way you also have less interuption and more customer steerage and feedback. 
       

      Steven A. Gordon, Ph.D.
      Manager, Software Factory
      Arizona State University
      PO Box 875506
      Tempe, AZ 85287-9509
      http://sf.asu.edu
      (480)-727-6271

       
      -----Original Message-----
      From: deborah@... [mailto:deborah@...]
      Sent: Tuesday, December 16, 2003 10:03 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: End of Sprint problem

      --- In scrumdevelopment@yahoogroups.com, Manish Singla
      <manish.singla@s...> wrote:
      > If we don't keep 5th week, when we will fix bugs???. Although, 5th
      week
      > is very unplanned and we need to do something. (We plan some bugs 
      for
      > next sprint).

      We also have to deal with an external QA step. We're still figuring
      out how to work, but so far what we do is:

      a) do as much testing as we can within the Sprint to reduce
      QA "recycles". Doing this reduces the likelihood of *critical* bugs
      coming back, those which would require an immediate branch to patch
      the code we are getting ready for release.

      b) estimate how much time we need to handle recycles, and compensate
      for this when planning Sprints/Releases. So you don't need a Sprint
      5, just start again with a Sprint 1 while testing goes on (I assume
      it is another team that tests?), and handle the recycles whenever
      they come back to you. Recycle development just gets rolled into the
      result of each Sprint (rare case: it is Critical, in which case we
      need to branch to fix it immediately so QA can continue)

      Because we are a development and support shop, we also have bugs
      coming in from our Live environment. We likewise factor in time for
      Live support in our Sprints, so we don't get taken by surprise. If
      there is no call for support or recycles, we can always add
      functionality to the Sprint.



      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...





      Yahoo! Groups Links

    Your message has been successfully submitted and would be delivered to recipients shortly.