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

RE: [SPAM] [scrumdevelopment] Bugs from previous Iteration

Expand Messages
  • Neeraj Deginal
    Kier, In such situation, the team should discuss with PO to identify the plan of action. In the most probable case, based on the criticality of bugs, the
    Message 1 of 12 , May 31, 2007
    • 0 Attachment

      Kier,

       

      In such situation, the team should discuss with PO to identify the plan of action. In the most probable case, based on the criticality of bugs, the running sprint is terminated; new sprint to fix bugs is initiated.

       

      In any case the decision is of PO, and team should have retrospect.

       

      Regards,

      Neeraj

       

      -----Original Message-----
      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Kier
      Sent: Friday, June 01, 2007 4:32 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: [SPAM] [scrumdevelopment] Bugs from previous Iteration
      Importance: Low

       

      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

    • 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 2 of 12 , May 31, 2007
      • 0 Attachment
        (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 3 of 12 , Jun 1, 2007
        • 0 Attachment
          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 4 of 12 , Jun 1, 2007
          • 0 Attachment
            (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 5 of 12 , Jun 1, 2007
            • 0 Attachment
              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 6 of 12 , Jun 1, 2007
              • 0 Attachment
                >
                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 7 of 12 , Jun 1, 2007
                • 0 Attachment
                  --- 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 8 of 12 , Jun 1, 2007
                  • 0 Attachment
                    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 9 of 12 , Jun 5, 2007
                    • 0 Attachment

                      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.