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

Re: [scrumdevelopment] How to cope with bugs ?

Expand Messages
  • Mark Levison
    Questions of when to fix them aside - I would start to ask the question why weren t they found and fixed within the sprint that they occured? My focus is on
    Message 1 of 23 , Jul 15, 2009
      Questions of when to fix them aside - I would start to ask the question why weren't they found and fixed within the sprint that they occured? My focus is on reducing the time it takes to discover (and then fix) problems. After all if we discover a bug in the story during the sprint it is written then the PO shoudl accept it as being done. In addition early discovery will make it much easier to fix as the code is still fresh in the mind of the development team.

      Cheers
      Mark

      Mark Levison - Agile/Lean Transition Coach ||Agile Editor @ InfoQ ||
      613-862-2538 (cell) || Twitter || Blog Recent Entries:
      Agile Mailing Lists a Survey || Do You Suspect You Have a Less than Productive Person on Your Team?




    • jmilunsky
      While we try diligently to find all issues during the sprint, it s not a guarantee that you will find them all. For example, a new version of the browser is
      Message 2 of 23 , Jul 15, 2009
        While we try diligently to find all issues during the sprint, it's not a guarantee that you will find them all.

        For example, a new version of the browser is launched and there is a browser compatability problem.

        Could be an issue that is specific to a particular end user machine config who knows.

        Bugs found during the sprint should be fixed in the same sprint, we all agree on that.

        All your points are valid - thanks

        Jack
        twitter.com/agilebuddy
        blog.agilebuddy.com
        www.agilebuddy.com

        --- In scrumdevelopment@yahoogroups.com, Mark Levison <mark@...> wrote:
        >
        > Questions of when to fix them aside - I would start to ask the question why
        > weren't they found and fixed within the sprint that they occured? My focus
        > is on reducing the time it takes to discover (and then fix) problems. After
        > all if we discover a bug in the story during the sprint it is written then
        > the PO shoudl accept it as being done. In addition early discovery will make
        > it much easier to fix as the code is still fresh in the mind of the
        > development team.
        >
        > Cheers
        > Mark
        >
        > Mark Levison - Agile/Lean Transition Coach || Agile Editor @
        > InfoQ<http://www.infoq.com/about.jsp>|| 613-862-2538
        > (cell) || Twitter <http://twitter.com/mlevison> ||
        > Blog<http://www.notesfromatooluser.com/>Recent Entries: Agile
        > Mailing Lists a
        > Survey<http://www.notesfromatooluser.com/2009/06/agile-mailing-lists.html>||
        > Do
        > You Suspect You Have a Less than Productive Person on Your
        > Team?<http://www.notesfromatooluser.com/2009/01/do-you-suspect-you-have-a-less-than-productive-person-on-your-team.html>
        >
        >
        > <http://www.notesfromatooluser.com/2009/01/do-you-suspect-you-have-a-less-than-productive-person-on-your-team.html>
        >
      • Mark Levison
        Sure there will always be new and interesting bugs found, I m just trying to force you to consider finding as many bugs as can be found sooner. If browser
        Message 3 of 23 , Jul 15, 2009
          Sure there will always be new and interesting bugs found, I'm just trying to force you to consider finding as many bugs as can be found sooner. If browser compatibility is big issue for you then I would ask if you're doing automated acceptance tests over all the browsers you care about.

          If its machine config thats a problem I would ask how many different (relevant) configurations you're testing.

          Cheers
          Mark

          On Wed, Jul 15, 2009 at 3:42 PM, jmilunsky <jack@...> wrote:
           

          While we try diligently to find all issues during the sprint, it's not a guarantee that you will find them all.

          For example, a new version of the browser is launched and there is a browser compatability problem.

          Could be an issue that is specific to a particular end user machine config who knows.

          Bugs found during the sprint should be fixed in the same sprint, we all agree on that.

          All your points are valid - thanks

          www.agilebuddy.com


          --- In scrumdevelopment@yahoogroups.com, Mark Levison <mark@...> wrote:
          >
          > Questions of when to fix them aside - I would start to ask the question why
          > weren't they found and fixed within the sprint that they occured? My focus
          > is on reducing the time it takes to discover (and then fix) problems. After
          > all if we discover a bug in the story during the sprint it is written then
          > the PO shoudl accept it as being done. In addition early discovery will make
          > it much easier to fix as the code is still fresh in the mind of the
          > development team.
          >
          > Cheers
          > Mark
          >
          > Mark Levison - Agile/Lean Transition Coach || Agile Editor @
          > InfoQ<http://www.infoq.com/about.jsp>|| 613-862-2538
          > (cell) || Twitter <http://twitter.com/mlevison> ||
          > Blog<http://www.notesfromatooluser.com/>Recent Entries: Agile
          > Mailing Lists a
          > Survey<http://www.notesfromatooluser.com/2009/06/agile-mailing-lists.html>||

          > Do
          > You Suspect You Have a Less than Productive Person on Your
          > Team?<http://www.notesfromatooluser.com/2009/01/do-you-suspect-you-have-a-less-than-productive-person-on-your-team.html>
          >
          >
          > <http://www.notesfromatooluser.com/2009/01/do-you-suspect-you-have-a-less-than-productive-person-on-your-team.html>
          >



          Mark Levison - Agile/Lean Transition Coach ||Agile Editor @ InfoQ ||
          613-862-2538 (cell) || Twitter || Blog Recent Entries:
          Agile Mailing Lists a Survey || Do You Suspect You Have a Less than Productive Person on Your Team?
        • juan_banda
          I d suggest that you create a separate user story for bug fixing for many reasons: 1. You need to keep track of the time and effort invested 2. Tasks withing
          Message 4 of 23 , Jul 16, 2009
            I'd suggest that you create a separate user story for bug fixing for many reasons:
            1. You need to keep track of the time and effort invested
            2. Tasks withing that bug fixing user story could correspond to specific prioritized bugs, in this way you'd have more granularity and visibility
            2. You need to estimate and plan for bug fixing, if not you might need to deviate time from development or other activities making the team loosing its focus

            Talking about prioritization, in my experience is good to have Quality Engineers categorizing bugs using a severity scale, but the PO should be the one in charge of assigning bugs priorities.

            A final word of caution, you can't defer PR fixing for later, try to fix as many high severity and high priority bugs in the current sprint as you can, otherwise you might be ending having a very buggy potential shippable product.

            Just my two cents,

            Juan

            --- In scrumdevelopment@yahoogroups.com, Jim Schiel <schiel@...> wrote:
            >
            > I don't know that you really need to create user stories for defects.
            > You can, however, put the defect on the backlog for it to be
            > prioritized by the Product Owner. Almost the same thing, but simpler.
            > You can groom the defect into a solution during the preceding Sprint
            > -- unless its a dead simple fix, in which case you determine the
            > solution during Sprint Planning and execute the solution during the
            > Sprint.
            >
            > Jim Schiel, CST
            > Artisan Software Consulting
            >
            > On Jul 9, 2009, at 5:11 PM, George Dinwiddie wrote:
            >
            > >
            > >
            > > Pascal Maugeri wrote:
            > > > Of course, I insisted a lot on what "done" means and if a proper
            > > > testing/unit-testing of developments is done, we should not
            > > theorically
            > > > have to spend a lot of time in bug fixing in the future. But still
            > > there
            > > > are bugs found in integration, etc.
            > >
            > > A good topic for the team during retrospectives. I've seen teams with
            > > vanishingly small bug rates.
            > >
            > > > So should I create user stories for bug fixing ?
            > >
            > > I think that's a good idea.
            > >
            > > > I don't like the idea of a sprint dedicated to bug fixing, so
            > > maybe a
            > > > mix of feature development and bug fixing is a good practice ?
            > >
            > > I would let the P.O. prioritize the bug stories along with new feature
            > > stories. It's really a business call. Some bugs are lower priority
            > > than new features and some are not.
            > >
            > > - George
            > >
            > > --
            > > ----------------------------------------------------------
            > > * George Dinwiddie * http://blog.gdinwiddie.com
            > > Software Development http://www.idiacomputing.com
            > > Consultant and Coach http://www.agilemaryland.org
            > > ----------------------------------------------------------
            > >
            > >
            > >
            >
          • Mark Levison
            Just for fun I summarized this thread on InfoQ: http://www.infoq.com/news/2009/07/coping-with-bugs - and there are a number of fairly vehement reactions: Fix
            Message 5 of 23 , Jul 16, 2009
              Just for fun I summarized this thread on InfoQ: http://www.infoq.com/news/2009/07/coping-with-bugs - and there are a number of fairly vehement reactions: "Fix Bug Now" (proposing a stop line the line mentality to bugs) and "Bug Driven Development is Evil"

              Cheers
              Mark
              Mark Levison - Agile/Lean Transition Coach ||Agile Editor @ InfoQ ||
              613-862-2538 (cell) || Twitter || Blog Recent Entries:
              Agile Mailing Lists a Survey || Do You Suspect You Have a Less than Productive Person on Your Team?
            • Roy Morien
              This is very good advice to a team that is using a traditional Waterfall type development approach. they would probably have enough bugs that they must have a
              Message 6 of 23 , Jul 16, 2009
                This is very good advice to a team that is using a traditional Waterfall type development approach. they would probably have enough bugs that they must have a bug tracking system. They would probably also have a separate group of Quality Engineers whose job it is to track bugs, prioritize the fixing of those bugs, and estimating and planning for the bugs to be fixed. 
                 
                And they will probably have a bug-management system for prioritising high severity and high priority bugs.
                 
                BUT this isn't a Scrum team. If the Scrum team is operating effectively, the Quality Engineers would be redundant as such, and their job would be integrated with multi-skilled developers work. If the Scrum team is operating effectively, there just wouldn't be a sufficient backlog of high severity and high priority bugs.
                 
                The initial question here seems to me to be 'Please give me advice on how to overcome a big problem that we have with bugs because we aren't actually using a Scrum approach at all, and we want a solution to the problems that this is bringing'.
                 
                The bugs are process-created, so change your process.
                 
                Regards,
                Roy morien


                To: scrumdevelopment@yahoogroups.com
                From: juan_banda@...
                Date: Thu, 16 Jul 2009 13:41:14 +0000
                Subject: [scrumdevelopment] Re: How to cope with bugs ?

                 
                I'd suggest that you create a separate user story for bug fixing for many reasons:
                1. You need to keep track of the time and effort invested
                2. Tasks withing that bug fixing user story could correspond to specific prioritized bugs, in this way you'd have more granularity and visibility
                2. You need to estimate and plan for bug fixing, if not you might need to deviate time from development or other activities making the team loosing its focus

                Talking about prioritization, in my experience is good to have Quality Engineers categorizing bugs using a severity scale, but the PO should be the one in charge of assigning bugs priorities.

                A final word of caution, you can't defer PR fixing for later, try to fix as many high severity and high priority bugs in the current sprint as you can, otherwise you might be ending having a very buggy potential shippable product.

                Just my two cents,

                Juan

                --- In scrumdevelopment@ yahoogroups. com, Jim Schiel <schiel@...> wrote:
                >
                > I don't know that you really need to create user stories for defects.
                > You can, however, put the defect on the backlog for it to be
                > prioritized by the Product Owner. Almost the same thing, but simpler.
                > You can groom the defect into a solution during the preceding Sprint
                > -- unless its a dead simple fix, in which case you determine the
                > solution during Sprint Planning and execute the solution during the
                > Sprint.
                >
                > Jim Schiel, CST
                > Artisan Software Consulting
                >
                > On Jul 9, 2009, at 5:11 PM, George Dinwiddie wrote:
                >
                > >
                > >
                > > Pascal Maugeri wrote:
                > > > Of course, I insisted a lot on what "done" means and if a proper
                > > > testing/unit- testing of developments is done, we should not
                > > theorically
                > > > have to spend a lot of time in bug fixing in the future. But still
                > > there
                > > > are bugs found in integration, etc.
                > >
                > > A good topic for the team during retrospectives. I've seen teams with
                > > vanishingly small bug rates.
                > >
                > > > So should I create user stories for bug fixing ?
                > >
                > > I think that's a good idea.
                > >
                > > > I don't like the idea of a sprint dedicated to bug fixing, so
                > > maybe a
                > > > mix of feature development and bug fixing is a good practice ?
                > >
                > > I would let the P.O. prioritize the bug stories along with new feature
                > > stories. It's really a business call. Some bugs are lower priority
                > > than new features and some are not.
                > >
                > > - George
                > >
                > > --
                > > ------------ --------- --------- --------- --------- --------- -
                > > * George Dinwiddie * http://blog. gdinwiddie. com
                > > Software Development http://www.idiacomp uting.com
                > > Consultant and Coach http://www.agilemar yland.org
                > > ------------ --------- --------- --------- --------- --------- -
                > >
                > >
                > >
                >




                Make ninemsn your homepage! Get the latest news, goss and sport
              • Jack Milunsky
                For sure that s what you try to do. But for example, we don t support beta versions of browsers and inevitably when the new version of the browser ships one
                Message 7 of 23 , Jul 16, 2009
                  For sure that's what you try to do. But for example, we don't support beta versions of browsers and inevitably when the new version of the browser ships one has to deal with the issues that surface. For example Firefox 3.5, when it shipped we had issues. Our app uses some sophisticated javascript etc so you don't know how it's going to affect you until they go live.

                  I have been in the software business for 20 years and I don't believe it's possible to nail absolutely every bug, no matter how good your process is. But we try hard. For example with Agilebuddy, we have 90% code coverage with our unit tests. But we still find issues. Some early some only in production. And we have an exact mirror of production on staging.

                  On Wed, Jul 15, 2009 at 3:48 PM, Mark Levison <mark@...> wrote:
                   

                  Sure there will always be new and interesting bugs found, I'm just trying to force you to consider finding as many bugs as can be found sooner. If browser compatibility is big issue for you then I would ask if you're doing automated acceptance tests over all the browsers you care about.

                  If its machine config thats a problem I would ask how many different (relevant) configurations you're testing.

                  Cheers
                  Mark



                  On Wed, Jul 15, 2009 at 3:42 PM, jmilunsky <jack@...> wrote:
                   

                  While we try diligently to find all issues during the sprint, it's not a guarantee that you will find them all.

                  For example, a new version of the browser is launched and there is a browser compatability problem.

                  Could be an issue that is specific to a particular end user machine config who knows.

                  Bugs found during the sprint should be fixed in the same sprint, we all agree on that.

                  All your points are valid - thanks

                  www.agilebuddy.com


                  --- In scrumdevelopment@yahoogroups.com, Mark Levison <mark@...> wrote:
                  >
                  > Questions of when to fix them aside - I would start to ask the question why
                  > weren't they found and fixed within the sprint that they occured? My focus
                  > is on reducing the time it takes to discover (and then fix) problems. After
                  > all if we discover a bug in the story during the sprint it is written then
                  > the PO shoudl accept it as being done. In addition early discovery will make
                  > it much easier to fix as the code is still fresh in the mind of the
                  > development team.
                  >
                  > Cheers
                  > Mark
                  >
                  > Mark Levison - Agile/Lean Transition Coach || Agile Editor @
                  > InfoQ<http://www.infoq.com/about.jsp>|| 613-862-2538
                  > (cell) || Twitter <http://twitter.com/mlevison> ||
                  > Blog<http://www.notesfromatooluser.com/>Recent Entries: Agile
                  > Mailing Lists a
                  > Survey<http://www.notesfromatooluser.com/2009/06/agile-mailing-lists.html>||

                  > Do
                  > You Suspect You Have a Less than Productive Person on Your
                  > Team?<http://www.notesfromatooluser.com/2009/01/do-you-suspect-you-have-a-less-than-productive-person-on-your-team.html>
                  >
                  >
                  > <http://www.notesfromatooluser.com/2009/01/do-you-suspect-you-have-a-less-than-productive-person-on-your-team.html>
                  >



                  Mark Levison - Agile/Lean Transition Coach ||Agile Editor @ InfoQ ||
                  613-862-2538 (cell) || Twitter || Blog Recent Entries:
                  Agile Mailing Lists a Survey ||
                  Do You Suspect You Have a Less than Productive Person on Your Team?

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