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

RE: [scrumdevelopment] Bugs from previous Iteration

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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.