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

RE: [scrumdevelopment] Bugs from previous Iteration

Expand Messages
  • Oldfield, Paul (ASPIRE)
    (responding to Kier) ... It s up to the PO to decide on priorities; the work you have planned for the iteration may be more important, or it may not. There are
    Message 1 of 12 , May 31, 2007
      (responding to Kier)

      > While working on the next iteration several bug
      > reports come in from the delivered code.
      >
      > Should we fix those in the current iteration
      > even though they weren't planned or should we
      > wait and prioritize them in the next iteration.
      >
      > I was thinking that I could have a Programmer
      > and BA in reserve to handle such issues.

      It's up to the PO to decide on priorities; the
      work you have planned for the iteration may be
      more important, or it may not.

      There are a couple of suggestions. In case you think
      this is a common occurrence, it may be sensible
      to get the PO to either plan in some time to spend
      working on top priority bugs, or to plan in some
      work that can be dropped in case any top priority
      bugs appear.

      Without either of these, you have a choice between
      3 options.
      1/ defer the bugfix and the PO can plan it into the
      next iteration.
      2/ Stop the iteration and re-plan (probably what you
      should do if the bug is critical and needs considerable
      work)
      3/ Slip the bugfix into your current plans for this
      iteration. Not recommended, but could be the
      pragmatic way to proceed for a current iteration
      until you get a way of dealing with the contingency
      agreed (i.e. you only ever do it once).

      It shouldn't need to be said that you should look
      for ways of ensuring bugs don't get into the
      product, so the situation will not arise in
      future. Okay, agreed, those skills take some time
      to learn and polish, and you have a body of code
      that hasn't been developed using TDD or similar,
      that may have bugs appearing for a while yet.

      Paul Oldfield
    • Mishkin Berteig
      My understanding of Ken s Canary in a Coal Mine talk is that defects should be handled by putting them at the top of the Product Backlog and only a C-level
      Message 2 of 12 , Jun 1, 2007
        My understanding of Ken's "Canary in a Coal Mine" talk is that defects should be handled by putting them at the top of the Product Backlog and only a C-level executive can de-prioritize them on a case-by-case basis.  This is in line with the related "lean" approach to removing waste.

        More here: Quality is Not Negotiable
         
        Mishkin Berteig
        mishkin@...
        http://www.agileadvice.com/
        "Truthfulness is the foundation of all human virtues" - Baha'u'llah


        ----- Original Message ----
        From: "Oldfield, Paul (ASPIRE)" <Paul.Oldfield@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Friday, June 1, 2007 2:55:28 AM
        Subject: RE: [scrumdevelopment] Bugs from previous Iteration

        (responding to Kier)

        > While working on the next iteration several bug
        > reports come in from the delivered code.
        >
        > Should we fix those in the current iteration
        > even though they weren't planned or should we
        > wait and prioritize them in the next iteration.
        >
        > I was thinking that I could have a Programmer
        > and BA in reserve to handle such issues.

        It's up to the PO to decide on priorities; the
        work you have planned for the iteration may be
        more important, or it may not.

        There are a couple of suggestions. In case you think
        this is a common occurrence, it may be sensible
        to get the PO to either plan in some time to spend
        working on top priority bugs, or to plan in some
        work that can be dropped in case any top priority
        bugs appear.

        Without either of these, you have a choice between
        3 options.
        1/ defer the bugfix and the PO can plan it into the
        next iteration.
        2/ Stop the iteration and re-plan (probably what you
        should do if the bug is critical and needs considerable
        work)
        3/ Slip the bugfix into your current plans for this
        iteration. Not recommended, but could be the
        pragmatic way to proceed for a current iteration
        until you get a way of dealing with the contingency
        agreed (i.e. you only ever do it once).

        It shouldn't need to be said that you should look
        for ways of ensuring bugs don't get into the
        product, so the situation will not arise in
        future. Okay, agreed, those skills take some time
        to learn and polish, and you have a body of code
        that hasn't been developed using TDD or similar,
        that may have bugs appearing for a while yet.

        Paul Oldfield




        Shape Yahoo! in your own image. Join our Network Research Panel today!
      • Oldfield, Paul (ASPIRE)
        (responding to Mishkin) ... This makes sense, but might not be practical where there s already a high technical debt. In a steady state of low technical
        Message 3 of 12 , Jun 1, 2007
          (responding to Mishkin)

          > My understanding of Ken's "Canary in a Coal Mine" talk is that
          > defects should be handled by putting them at the top of the
          > Product Backlog and only a C-level executive can de-prioritize
          > them on a case-by-case basis. This is in line with the related
          > "lean" approach to removing waste.

          This makes sense, but might not be practical where there's already
          a high technical debt. In a 'steady state' of low technical debt,
          putting new defects to the top of the backlog so they get into
          the next sprint is what I would want to do. Don't let the path by
          which the defect crept into the product remain open.

          From a practical point of view, one should be able to try out
          the process improvements on new functionality, so fixing
          defects where there is high technical debt might need to be
          folded in with new work to exercise the improved process.

          Paul Oldfield
        • Dave Nicolette
          I ve seen projects that leave time and people aside to deal with bugs mid-sprint; I can see how a team might have to resort to that, but I think it may be a
          Message 4 of 12 , Jun 1, 2007
            I've seen projects that leave time and people aside to deal with bugs
            mid-sprint; I can see how a team might have to resort to that, but I
            think it may be a "process smell." Two questions come to mind. First,
            why are so many defects being produced? Second, why can't the defects
            be prioritized by the PO for a future sprint; that is, why can't the
            fixes wait?

            These may be different problems that call for different solutions.
            Could be a good topic for the next retrospective.

            If the problem is that the team is producing more defects than one
            would normally expect in the course of development, then maybe the
            team needs to reconsider its development/testing practices. Are they
            doing TDD? Are they doing code reviews? Is the build taking too long
            to run, and therefore discouraging developers from using good practices?

            This smell may also be caused by poor communication with (or low
            participation by) the PO. Are the developers getting the information
            they need about /what/ to build? Maybe the defects aren't programming
            bugs at all, but misunderstood or incomplete requirements.

            If the problem is that the PO can't afford to leave defects unfixed
            until the next sprint, then maybe the sprint length is too long. If
            the team is doing, say, four-week sprints, maybe they could try
            two-week sprints. It's possible that with two-week sprints, the
            urgency would be alleviated and it would become feasible to put the
            defects on the backlog for consideration in the next sprint planning
            meeting.

            Dave

            --- In scrumdevelopment@yahoogroups.com, "Oldfield, Paul \(ASPIRE\)"
            <Paul.Oldfield@...> wrote:
            >
            > (responding to Mishkin)
            >
            > > My understanding of Ken's "Canary in a Coal Mine" talk is that
            > > defects should be handled by putting them at the top of the
            > > Product Backlog and only a C-level executive can de-prioritize
            > > them on a case-by-case basis. This is in line with the related
            > > "lean" approach to removing waste.
            >
            > This makes sense, but might not be practical where there's already
            > a high technical debt. In a 'steady state' of low technical debt,
            > putting new defects to the top of the backlog so they get into
            > the next sprint is what I would want to do. Don't let the path by
            > which the defect crept into the product remain open.
            >
            > From a practical point of view, one should be able to try out
            > the process improvements on new functionality, so fixing
            > defects where there is high technical debt might need to be
            > folded in with new work to exercise the improved process.
            >
            > Paul Oldfield
            >
          • Gregor Dodson
            ... planned Yes. There will always be bugs, and they always need to be addressed. Our team is constantly releasing, since our internal customers always want to
            Message 5 of 12 , Jun 1, 2007
              >
              Should we fix those in the current iteration even though they weren't
              planned

              Yes. There will always be bugs, and they always need to be addressed.

              Our team is constantly releasing, since our internal customers always want to use the latest version of our software, so bugs need to be handled quickly. We just deal with them and move on. Our velocity suffers, but we expect there to always be some bugs, so it all comes out in the wash.

              Of course, you have to be careful that they really are bugs and not feature requests dressed in sheeps clothing.


              On 5/31/07, Kier < kieroneil@...> wrote:

              Let's say that an iteration is complete and delivered to customers.

              While working on the next iteration several bug reports come in from
              the delivered code.

              Should we fix those in the current iteration even though they weren't
              planned or should we wait and prioritize them in the next iteration.

              I was thinking that I could have a Programmer and BA in reserve to
              handle such issues.

              Please give your opinions...

              Sincerely,
              Kier
              Jacksonville, FL




              --
              I rather like the idea of being thought of as a shit  - a common conceit among those who don't realize just how shitty they really are." - Clive James
            • Kane Mar
              ... Ideally I would want to prevent this from happening. There are some concrete steps I personally take to achieve this: 1. Have a discussion with the team
              Message 6 of 12 , Jun 1, 2007
                --- In scrumdevelopment@yahoogroups.com, "Kier" <kieroneil@...> wrote:
                >
                > Let's say that an iteration is complete and delivered to customers.
                >
                > While working on the next iteration several bug reports come in from
                > the delivered code.

                Ideally I would want to prevent this from happening. There are some
                concrete steps I personally take to achieve this:

                1. Have a discussion with the team about what "Done" means. I would
                suggest that the definition of "Done" (at the very least) include:
                Analysis, design, coding, testing and some level of end-to-end
                functionality testing. In other words, all those activities need to be
                included for something to be considered "Done".

                2. Introduce the concept of "No new bugs for any new functionality".
                In other words new functionality is only considered "Done" if there
                are no outstanding bugs.

                Adopting both of these steps will force the team to change it's
                behaviour. In order to achieve these goals the testers will need to
                get involved earlier and it will force the developers to deliver
                earlier and more often.

                Please keep us informed of your progress and what works for you.

                Best regards,
                Kane Mar
                B: http://www.KaneMar.com
                W: http://www.Danube.com
              • Kier
                Dave et al, The real problem is that we don t have our customers as involved as we should. Our BA s talk to our customers and our PO talks to our Sales &
                Message 7 of 12 , Jun 1, 2007
                  Dave et al,
                  The real problem is that we don't have our customers as involved as we
                  should. Our BA's talk to our customers and our PO talks to our Sales
                  & Marketing folks to determine user needs.

                  We are just now heading into our first iteration using scrum so it is
                  possible that the usual post-release bugs will not materialize using
                  the Scrum methodology.
                  In Waterfall it was inevitable that there would be a handful of tweaks
                  to be made post-delivery.

                  On this particular product we also have no automated testing either.
                  One of these days ...

                  Cheers,
                  Kier
                  Jacksonville, FL
                • Nicholas Cancelliere
                  This depends on how bad the bug is. Is your customer willing to wait until the defect is planned, to be worked on. Or are they so angry they re ready to quit
                  Message 8 of 12 , Jun 5, 2007

                    This depends on how bad the bug is.  Is your customer willing to wait until the defect is planned, to be worked on.  Or are they so angry they're ready to quit tomorrow?

                    In any case you'll have to end up dealing with the defect (either unplanned in the current iteration, or planned in the next).  Defects become a "debt" on your productivity, and if the quality is poor you'll find yourself scheduling more defects than features (or your velocity is lower because in a given sprint there are any number of unplanned defects to be worked on).

                    Do you usually have a lot of in-production defects?  Are they usually critical or just minor things?  Do you practice TDD or any XP methods that might help reduce the errors in production?

                    Nicholas



                    On May 31, 2007, at 6:02 PM, Kier wrote:

                    Let's say that an iteration is complete and delivered to customers.

                    While working on the next iteration several bug reports come in from
                    the delivered code.

                    Should we fix those in the current iteration even though they weren't
                    planned or should we wait and prioritize them in the next iteration.

                    I was thinking that I could have a Programmer and BA in reserve to
                    handle such issues.

                    Please give your opinions...

                    Sincerely,
                    Kier
                    Jacksonville, FL


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