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

bugs and sprint resets

Expand Messages
  • mikeborozdin
    I d like to know how people deal with the following situation: In the middle of a sprint your customer finds a bug in the version that is distributed and of
    Message 1 of 6 , Aug 5, 2004
    • 0 Attachment
      I'd like to know how people deal with the following situation:

      In the middle of a sprint your customer finds a bug in the version
      that is distributed and of course needs a patch or a fixed version
      right away.

      Several things that the team can do at this point:
      - Create a patch. This will obviously create thrashing. Still from
      the customer perspective waiting 3 weeks for a fix to a data loss or
      a data corruption bug is unacceptable.

      - Add the item to the current sprint. This could be good if the bug
      doesn't stop the main function of the software.

      - Split up the team to people who go off and fix stuff and have
      other people go according to the sprint plan.

      - Scrap the entire sprint, fix the patch and then start the sprint
      over.

      And I am sure there are many more other ways of dealing with this.
      I am curious what people do in those cases. Thanks!
    • Mike Cohn
      My reaction in this case somewhat depends on our expectations going into the sprint. For example, I am working with a team now with a medium-sized java code
      Message 2 of 6 , Aug 5, 2004
      • 0 Attachment
        My reaction in this case somewhat depends on our expectations going into the
        sprint.

        For example, I am working with a team now with a medium-sized java code base
        but one with a lot of legacy bugs. The team has been doing Scrum for 7
        months and has made great progress toward paying off the legacy technical
        debt. When we first started it was a given that we'd get customer-reported
        issues that would need to be fixed in the sprint. We didn't know what they
        would be, of course, but we knew that some would come in. We just factored
        this into what we could commit to during the Sprint Planning Meeting. As
        time has passed and we have fewer and fewer issues coming up we can commit
        to a bit more each sprint.

        Our sprints are 2-weeks, rather than 30 days and we've now established bug
        definitions as follows:
        Showstopper--a bug that needs to be fixed today
        High - a bug that needs to be fixed in the current sprint
        Normal/Medium/Low--bugs that will be discussed in the next sprint planning
        meeting

        As an opposite case, suppose your code quality is high and you don't expect
        any bugs to be found during the sprint. In that case, I think it comes down
        to a corporate policy on customer responsiveness. Is responsiveness the top
        priority? If so, fix the bug with whoever is needed and then let the team
        recover the best they can against the sprint goal. If progress against new
        features is higher priority than responsiveness, tell the customer to wait
        (an average of 3 weeks with 2 week sprints) and fix it next sprint (if it's
        prioritized in).

        --Mike Cohn
        Author of User Stories Applied for Agile Software Development
        www.userstories.com
        www.mountaingoatsoftware.com


        -----Original Message-----
        From: mikeborozdin [mailto:EZXS@...]
        Sent: Thursday, August 05, 2004 3:36 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] bugs and sprint resets

        I'd like to know how people deal with the following situation:

        In the middle of a sprint your customer finds a bug in the version
        that is distributed and of course needs a patch or a fixed version
        right away.

        Several things that the team can do at this point:
        - Create a patch. This will obviously create thrashing. Still from
        the customer perspective waiting 3 weeks for a fix to a data loss or
        a data corruption bug is unacceptable.

        - Add the item to the current sprint. This could be good if the bug
        doesn't stop the main function of the software.

        - Split up the team to people who go off and fix stuff and have
        other people go according to the sprint plan.

        - Scrap the entire sprint, fix the patch and then start the sprint
        over.

        And I am sure there are many more other ways of dealing with this.
        I am curious what people do in those cases. Thanks!




        To Post a message, send it to: scrumdevelopment@...
        To Unsubscribe, send a blank message to:
        scrumdevelopment-unsubscribe@...
        Yahoo! Groups Links
      • Mike Dwyer
        We got to a point where we leave a certain amount of time available in the sprint to handle problems. (BTW a problem here is defined as anything that holds up
        Message 3 of 6 , Aug 5, 2004
        • 0 Attachment

          We got to a point where we leave a certain amount of time available in the sprint to handle problems. (BTW a problem here is defined as anything that holds up a user from getting their work done.)  If the problems the customer wants fixed begin to infringe on the new product sprint resource time, then we ask the customer to choose between the fix or the sprint. 

           

          We got to this through a compromise with the customer.  We were at a point where we had a similar problem ranking approach but that led to an endless conversation as to what was a problem and . . . .   This went away when we gave total control of the product priorities to the customer/user – with the following provisos

          1: IT would only implement business rules that the customer defined and that we would only deploy those solutions the customer accepted. 

          2: The customer would accept the work estimates of IT based on the business rules provided.  As the business improved the rules, IT tightened up the estimates.

           

          The net result is that the priorities became how much could be done in a limited amount of time.  Funny thing is the business people who spent more time providing better defined rules got more things fixed because the business owner of the product made the decision.  All we did is our job.

           

          -----------------------------------------

          Mike Dwyer

           

          -----Original Message-----
          From: Mike Cohn [mailto:mike@...]
          Sent:
          Thursday, August 05, 2004 5:54 PM
          To:
          scrumdevelopment@yahoogroups.com
          Subject: RE: [scrumdevelopment] bugs and sprint resets

           

          My reaction in this case somewhat depends on our expectations going into the
          sprint.

          For example, I am working with a team now with a medium-sized java code base
          but one with a lot of legacy bugs. The team has been doing Scrum for 7
          months and has made great progress toward paying off the legacy technical
          debt. When we first started it was a given that we'd get customer-reported
          issues that would need to be fixed in the sprint. We didn't know what they
          would be, of course, but we knew that some would come in. We just factored
          this into what we could commit to during the Sprint Planning Meeting.  As
          time has passed and we have fewer and fewer issues coming up we can commit
          to a bit more each sprint.

          Our sprints are 2-weeks, rather than 30 days and we've now established bug
          definitions as follows:
          Showstopper--a bug that needs to be fixed today
          High - a bug that needs to be fixed in the current sprint
          Normal/Medium/Low--bugs that will be discussed in the next sprint planning
          meeting

          As an opposite case, suppose your code quality is high and you don't expect
          any bugs to be found during the sprint. In that case, I think it comes down
          to a corporate policy on customer responsiveness. Is responsiveness the top
          priority? If so, fix the bug with whoever is needed and then let the team
          recover the best they can against the sprint goal. If progress against new
          features is higher priority than responsiveness, tell the customer to wait
          (an average of 3 weeks with 2 week sprints) and fix it next sprint (if it's
          prioritized in).

          --Mike Cohn
          Author of User Stories Applied for Agile Software Development
          www.userstories.com
          www.mountaingoatsoftware.com 


          -----Original Message-----
          From: mikeborozdin [mailto:EZXS@...]
          Sent:
          Thursday, August 05, 2004 3:36 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] bugs and sprint resets

          I'd like to know how people deal with the following situation:

          In the middle of a sprint your customer finds a bug in the version
          that is distributed and of course needs a patch or a fixed version
          right away.

          Several things that the team can do at this point:
          - Create a patch.  This will obviously create thrashing. Still from
          the customer perspective waiting 3 weeks for a fix to a data loss or
          a data corruption bug is unacceptable.

          - Add the item to the current sprint.  This could be good if the bug
          doesn't stop the main function of the software.

          - Split up the team to people who go off and fix stuff and have
          other people go according to the sprint plan.

          - Scrap the entire sprint, fix the patch and then start the sprint
          over.

          And I am sure there are many more other ways of dealing with this. 
          I am curious what people do in those cases.  Thanks!




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







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




        • David A Barrett
          To my mind there is really only one question: Can the bug be addressed without affecting the Sprint deliverables? If the answer is, No , then you have two
          Message 4 of 6 , Aug 6, 2004
          • 0 Attachment
            To my mind there is really only one question: Can the bug be addressed
            without affecting the Sprint deliverables?

            If the answer is, "No", then you have two courses of action:

            1. Terminate the current sprint.
            2. Suspend the current sprint, fix the bug, adjust the sprint end date,
            and resume the sprint.

            I was going to suggest a third, to swap the bug fix with some other sprint
            backlog item, but I decided against it. This might work iff the current
            sprint end date is close enough to be a suitable delivery date for the bug
            fix. I'm not sure that you want to get into the habit of letting the users
            muck with the priorities after the sprint has started.

            Personally, I lean towards option 1. This really puts it to the customer
            to decide if the bug fix is so important that everything else must be
            dropped.

            Beyond that, I agree with with Mike. I build in a 50% factor into our
            available man day calculation for the sprint. This accounts for the
            constant background noise of support requests, meetings, and bug fixing to
            which the developers are subjected. With this factor built in, a bug that
            takes a man day or two to fix isn't going to derail the sprint. If it is
            bigger than that then we try to put it on the PB. If the customer balked,
            I'd ask that first question to the team and then offer to terminate the
            sprint if the answer was, "No".

            Dave Barrett,
            Lawyers' Professional Indemnity Company
          • bschatz@primavera.com
            We faced this issue many times when we began using scrum and we chose to solve it by creating a scrum team that focuses primarily on customer support issues,
            Message 5 of 6 , Aug 6, 2004
            • 0 Attachment

              We faced this issue many times when we began using scrum and we chose to solve it by creating a scrum team that focuses primarily on customer support issues, and when they're not doing that, they work on other innovative projects that always seem to be on the sidelines. We rotate the team every month using people from other teams. This has worked extremely well for us and has resulted in increased customer satisfaction, increased ability to respond quickly, better appreciation for the customer's pain from the development team, and we've made much better progress on moving some of these side initiatives forward. In addition, the backlog of items that always seem to get stuck in the queue is shrinking rapidly. We put out quarterly patches for most issues, and if there is a priority 1 item as you described, we provide a quick patch. The team follows the same scrum process and reports out to the stakeholders at the sprint review. We've even included a member of the Support staff on the team.

              Bob Schatz
              Primavera Systems, Inc.


              "mikeborozdin" <EZXS@...>

              08/05/2004 05:35 PM

              Please respond to
              scrumdevelopment@yahoogroups.com

              To
              scrumdevelopment@yahoogroups.com
              cc
              Subject
              [scrumdevelopment] bugs and sprint resets





              I'd like to know how people deal with the following situation:

              In the middle of a sprint your customer finds a bug in the version
              that is distributed and of course needs a patch or a fixed version
              right away.

              Several things that the team can do at this point:
              - Create a patch.  This will obviously create thrashing. Still from
              the customer perspective waiting 3 weeks for a fix to a data loss or
              a data corruption bug is unacceptable.

              - Add the item to the current sprint.  This could be good if the bug
              doesn't stop the main function of the software.

              - Split up the team to people who go off and fix stuff and have
              other people go according to the sprint plan.

              - Scrap the entire sprint, fix the patch and then start the sprint
              over.

              And I am sure there are many more other ways of dealing with this.  
              I am curious what people do in those cases.  Thanks!



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


              Yahoo! Groups Sponsor
              ADVERTISEMENT
              click here




              Yahoo! Groups Links
            • Rand Bradley
              Bob - this is a great idea. It would seem to address the issue of Developers getting stuck in the Sustaining Engineering role. ... From:
              Message 6 of 6 , Aug 6, 2004
              • 0 Attachment
                Bob - this is a great idea. It would seem to address the issue of
                Developers getting stuck in the "Sustaining Engineering" role.


                ----- Original Message -----
                From: bschatz@... <bschatz@...>
                Date: Fri, 6 Aug 2004 09:18:46 -0400
                Subject: Re: [scrumdevelopment] bugs and sprint resets
                To: scrumdevelopment@yahoogroups.com


                We faced this issue many times when we began using scrum and we chose
                to solve it by creating a scrum team that focuses primarily on
                customer support issues, and when they're not doing that, they work on
                other innovative projects that always seem to be on the sidelines. We
                rotate the team every month using people from other teams. This has
                worked extremely well for us and has resulted in increased customer
                satisfaction, increased ability to respond quickly, better
                appreciation for the customer's pain from the development team, and
                we've made much better progress on moving some of these side
                initiatives forward. In addition, the backlog of items that always
                seem to get stuck in the queue is shrinking rapidly. We put out
                quarterly patches for most issues, and if there is a priority 1 item
                as you described, we provide a quick patch. The team follows the same
                scrum process and reports out to the stakeholders at the sprint
                review. We've even included a member of the Support staff on the team.

                Bob Schatz
                Primavera Systems, Inc.



                "mikeborozdin" <EZXS@...>

                08/05/2004 05:35 PM

                Please respond to
                scrumdevelopment@yahoogroups.com


                To scrumdevelopment@yahoogroups.com

                cc

                Subject [scrumdevelopment] bugs and sprint resets





                I'd like to know how people deal with the following situation:

                In the middle of a sprint your customer finds a bug in the version
                that is distributed and of course needs a patch or a fixed version
                right away.

                Several things that the team can do at this point:
                - Create a patch. This will obviously create thrashing. Still from
                the customer perspective waiting 3 weeks for a fix to a data loss or
                a data corruption bug is unacceptable.

                - Add the item to the current sprint. This could be good if the bug
                doesn't stop the main function of the software.

                - Split up the team to people who go off and fix stuff and have
                other people go according to the sprint plan.

                - Scrap the entire sprint, fix the patch and then start the sprint
                over.

                And I am sure there are many more other ways of dealing with this.
                I am curious what people do in those cases. Thanks!



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



                Yahoo! Groups Sponsor


                ADVERTISEMENT




                ________________________________
                Yahoo! Groups Links
                To visit your group on the web, go to:
                http://groups.yahoo.com/group/scrumdevelopment/

                To unsubscribe from this group, send an email to:
                scrumdevelopment-unsubscribe@yahoogroups.com

                Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



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



                Yahoo! Groups Sponsor

                ADVERTISEMENT


                ________________________________
                Yahoo! Groups Links

                To visit your group on the web, go to:
                http://groups.yahoo.com/group/scrumdevelopment/

                To unsubscribe from this group, send an email to:
                scrumdevelopment-unsubscribe@yahoogroups.com

                Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



                --
                Kind Regards,

                Rand Bradley
                PROJECTWAY, LLC
                Phone: (415) 409-9709
                Mobile: (415) 939-6883
                Email: rbradley@...
                http://www.projectway.com
              Your message has been successfully submitted and would be delivered to recipients shortly.