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

Re: Bug tracking and big tasks

Expand Messages
  • woynam
    I wouldn t consider Task B an impediment to Task A. Typically, an impediment is something *outside* the team. In this example, simply move Task A back to Not
    Message 1 of 19 , May 5, 2010
    • 0 Attachment
      I wouldn't consider Task B an impediment to Task A. Typically, an impediment is something *outside* the team.

      In this example, simply move Task A back to "Not Started", or whatever state that represents work not in progress. It will have an estimate of 5, which was the work remaining on it at the time you discovered the new task. Since you started Task B, it should show as active.

      Mark

      --- In scrumdevelopment@yahoogroups.com, Rafael Nascimento <rafaelnascimento.rj@...> wrote:
      >
      > Yeah, it helps Alan! Thanx a lot!
      >
      > The only specific doubt that still in my mind is: I'm working in task A,
      > that takes 8 hours to be finished. At hour 3 of this task, I find a new task
      > I couldn't see before that will take 4 hours to be finished. Task B. So, I
      > start to work on the task B. But what happens with task A, on the Scrum
      > board? It has an impediment, or it still ongoing, since task B is "inside"
      > task A?
      >
      > Best regards!
      >
      > 2010/5/4 Alan Dayley <alandd@...>
      >
      > >
      > >
      > > Rafael,
      > >
      > > There are many correct answers to your question since every company or
      > > project or team could have something that works for them. Here are my
      > > suggested answers.
      > >
      > > 1. Your team or project or whole company should have a work agreement about
      > > how bugs are handled. There should be a way to publish them, a way to
      > > prioritize them and a way to schedule them to be fixed. We strive to follow
      > > these rules:
      > >
      > > - A bug found is fixed immediately if it is needed to finish a story in the
      > > current sprint. This is because a story is not considered Done if there are
      > > any bugs open against the story.
      > > - A bug that takes longer than one day to fix is published in the bug
      > > tracking system and reported at the Daily Scrum meeting.
      > > - A bug found that is not blocking a current story is published in the bug
      > > tracking system.
      > > - All open bugs are reviewed once a Sprint to understand priority and
      > > schedule them for correction.
      > > -- If it takes too long to review all the bugs, you have too many open,
      > > find out why so many and correct.
      > > - Bugs are scheduled into the Product Backlog during grooming along with
      > > the new features.
      > > - Bugs are not closed, meaning not considered done, until automated tests
      > > are written, shown to find the bug and incorporated into the test suite.
      > >
      > > Now, I subscribe to the idea that tracking bugs is waste and a bug found
      > > should be fixed immediately. This is not always accepted by other members
      > > of the Scrum Team so, the above is our current state.
      > >
      > > 2. The Sprint Backlog is the list of stories or features that are committed
      > > to be completed by the end of the Sprint. The tasks required to complete a
      > > given story are not as important as getting the story done. Therefore, if a
      > > task needs to be divided, divide it. If some tasks are not needed to finish
      > > a story, get rid of them. Tasks can come and go as long as the story gets
      > > done. Tasks are there to help the team estimate the size of the story and
      > > to track story progress to Done. Divide and combine tasks in ways that help
      > > you see when something goes wrong but don't spend too much time working on
      > > defining tasks beyond providing the needed visibility of progress or
      > > problems.
      > >
      > > 2a. If it is found that the story is too big for the Sprint, time to
      > > involve the Product Owner to discuss what will be not done by the end of the
      > > Sprint.
      > >
      > > Does that help?
      > >
      > > Alan
      > >
      > > On Tue, May 4, 2010 at 5:43 PM, Rafael Nascimento <
      > > rafaelnascimento.rj@...> wrote:
      > >
      > >>
      > >>
      > >> Hi friends!
      > >>
      > >> I'm a newbie CSM in a big brazillian project and I have 2 huge doubts:
      > >>
      > >> 1. How do you usually bug track in a sprint? These found bugs are resolved
      > >> during the actual sprint or they become new stories to be prioritized in the
      > >> next sprint? And, if it is resolved in the actual sprint, what about the
      > >> time estimate issue about this "new" task?
      > >>
      > >> 2. How do you often divide your oversized tasks when you discover that it
      > >> needs to be divided during its development?
      > >>
      > >> Thanks in advance!
      > >>
      > >> Best regards!
      > >> Rafael Nascimento
      > >>
      > >
      > >
      > >
      >
    • Rafael Nascimento
      Hey Ken! I didn t know about this event. Where can I find details? 2010/5/4 Ken Schwaber
      Message 2 of 19 , May 5, 2010
      • 0 Attachment
        Hey Ken!

        I didn't know about this event. Where can I find details?




        2010/5/4 Ken Schwaber <ken.schwaber@...>
         

        Come to the famed Brazilian Scrum day on July 24 and find out!!

        Ken

        On May 4, 2010, at 8:43 PM, Rafael Nascimento wrote:

         

        Hi friends!

        I'm a newbie CSM in a big brazillian project and I have 2 huge doubts:

        1. How do you usually bug track in a sprint? These found bugs are resolved during the actual sprint or they become new stories to be prioritized in the next sprint? And, if it is resolved in the actual sprint, what about the time estimate issue about this "new" task?

        2. How do you often divide your oversized tasks when you discover that it needs to be divided during its development?

        Thanks in advance!

        Best regards!
        Rafael Nascimento



      • Maurice le Rutte
        Rafael Nascimento schreef:   The only specific doubt that still in my mind is: I m working in task A, that takes 8 hours to be finished. At hour 3 of this
        Message 3 of 19 , May 5, 2010
        • 0 Attachment
          Rafael Nascimento schreef:
           


          The only specific doubt that still in my mind is: I'm working in task A, that takes 8 hours to be finished. At hour 3 of this task, I find a new task I couldn't see before that will take 4 hours to be finished. Task B. So, I start to work on the task B. But what happens with task A, on the Scrum board? It has an impediment, or it still ongoing, since task B is "inside" task A?

          You have found out new information, a new way to reach your goal. That's good. Now simply update your plan. I'd rebrand you task A to what you actually did there. So let's call it A1. This task is finished. Then create two new tasks B & C. Where C would be the second part of A. B & C get new estimates and are handled just as the rest.

          Maurice le Rutte.
          --
          http://www.scrummaster.nl / http://twitter.com/scrumnl
        • Michael James
          While I missed most of this discussion, I m compelled to point out this is perfectly normal, especially with complex work such as new product development. When
          Message 4 of 19 , May 5, 2010
          • 0 Attachment
            While I missed most of this discussion, I'm compelled to point out this is perfectly normal, especially with complex work such as new product development.

            When starting Scrum, it might be useful to distinguish PBIs from tasks.

            Last month I promised my wife we'd get a car, so I committed that Product Backlog Item to the Sprint.  (This is new development for me since I haven't owned any four-wheeled vehicle for years.)  One of the tasks required to meet the "done" criteria for that PBI was to transfer the title and register it.  At the registration office I discovered the car would have to go through emissions testing, so that's a new task for the same PBI.  At the emissions station I discovered the car needed some minor repairs, yet another task added to the same PBI.  After getting those done, I can finally do the task I'd originally identified.

            Note that no new scope was added to the Sprint -- my Product Owner (wife) didn't suddenly demand a fancier car.  In this case if I'd done more up front research, planning, and analysis maybe I'd have estimated the work better.  In the case of new product development, inventing something that's never existed before, trying to do too much speculative analysis up front will probably prevent development more than it will help.

            One of Ken's books states that only about 60% of the tasks to accomplish the Sprint Goals will be identified at the planning meeting.  That matches what I've seen for new product development.

            --mj

            On May 5, 2010, at 11:11 AM, Maurice le Rutte wrote:

             

            Rafael Nascimento schreef:

             


            The only specific doubt that still in my mind is: I'm working in task A, that takes 8 hours to be finished. At hour 3 of this task, I find a new task I couldn't see before that will take 4 hours to be finished. Task B. So, I start to work on the task B. But what happens with task A, on the Scrum board? It has an impediment, or it still ongoing, since task B is "inside" task A?

            You have found out new information, a new way to reach your goal. That's good. Now simply update your plan. I'd rebrand you task A to what you actually did there. So let's call it A1. This task is finished. Then create two new tasks B & C. Where C would be the second part of A. B & C get new estimates and are handled just as the rest.

            Maurice le Rutte.
            --
            http://www.scrummas ter.nl / http://twitter. com/scrumnl


          • Rafael Nascimento
            Thanks a lot Michael! Though I m a newbie SM, I already felt the same about the 60% of the tasks. 2010/5/5 Michael James
            Message 5 of 19 , May 5, 2010
            • 0 Attachment
              Thanks a lot Michael!
              Though I'm a newbie SM, I already felt the same about the 60% of the tasks.

              2010/5/5 Michael James <michael@...>
               

              While I missed most of this discussion, I'm compelled to point out this is perfectly normal, especially with complex work such as new product development.


              When starting Scrum, it might be useful to distinguish PBIs from tasks.

              Last month I promised my wife we'd get a car, so I committed that Product Backlog Item to the Sprint.  (This is new development for me since I haven't owned any four-wheeled vehicle for years.)  One of the tasks required to meet the "done" criteria for that PBI was to transfer the title and register it.  At the registration office I discovered the car would have to go through emissions testing, so that's a new task for the same PBI.  At the emissions station I discovered the car needed some minor repairs, yet another task added to the same PBI.  After getting those done, I can finally do the task I'd originally identified.

              Note that no new scope was added to the Sprint -- my Product Owner (wife) didn't suddenly demand a fancier car.  In this case if I'd done more up front research, planning, and analysis maybe I'd have estimated the work better.  In the case of new product development, inventing something that's never existed before, trying to do too much speculative analysis up front will probably prevent development more than it will help.

              One of Ken's books states that only about 60% of the tasks to accomplish the Sprint Goals will be identified at the planning meeting.  That matches what I've seen for new product development.

              --mj


              On May 5, 2010, at 11:11 AM, Maurice le Rutte wrote:

               

              Rafael Nascimento schreef:

               


              The only specific doubt that still in my mind is: I'm working in task A, that takes 8 hours to be finished. At hour 3 of this task, I find a new task I couldn't see before that will take 4 hours to be finished. Task B. So, I start to work on the task B. But what happens with task A, on the Scrum board? It has an impediment, or it still ongoing, since task B is "inside" task A?

              You have found out new information, a new way to reach your goal. That's good. Now simply update your plan. I'd rebrand you task A to what you actually did there. So let's call it A1. This task is finished. Then create two new tasks B & C. Where C would be the second part of A. B & C get new estimates and are handled just as the rest.

              Maurice le Rutte.
              --
              http://www.scrummaster.nl / http://twitter.com/scrumnl



            • Roy Morien
              It seems to me that if your are finding bugs or that you have open bugs to review and you need a bug tracking system that publishes bugs every day for the
              Message 6 of 19 , May 9, 2010
              • 0 Attachment
                It seems to me that if your are 'finding bugs' or that you have 'open bugs to review' and you need a bug tracking system that publishes bugs every day for the Scrum meeting ... you have a fundamental problem right from the start. The quite reasonable 'rule' is that a story is not DONE until it is deliverable, bug-free. So having open bugs and recording them in a bug tracking system surely implies that you are just not getting Stories DONE!
                 
                Of course, to a certain extent this does need a definition of a bug. If a bug is defined as an error in the processing activity, such that the processing is not being done according to understood requirements, then, Yes, you have a bug which should not exist once the functionality is delivered, unless you are delivering functionality that is not DONE. If a bug is defined as an identified change to delivered processing functionality, then that is not, in my view, a bug. It is a new requirement. This is understandable and acceptable, because ... things can change, people can learn!
                 
                I find it hard to understand why tracking bugs is not considered a waste, and why the Scrum team does not accept fixing bugs immediately. Accumulating bugs can surely have a detrimental affect on further development. I can see it quite obviously that time and effort might go into searching for a bug in curretn development, where it is really the effect of a bug that is still sitting in the Bug Tracking System waiting to be fixed at some time in the future, when the Scrum team decides it has been tracked long enough.
                 
                So, to me, the whole concept of 'tracking bugs' is a bad smell! Which also goes for trying to measure quality improvement by the reduction in known bugs at any given time.
                 
                Regards,
                Roy Morien
                 

                To: scrumdevelopment@yahoogroups.com
                From: alandd@...
                Date: Tue, 4 May 2010 19:13:53 -0700
                Subject: Re: [scrumdevelopment] Bug tracking and big tasks

                 
                Rafael,

                There are many correct answers to your question since every company or project or team could have something that works for them.  Here are my suggested answers.

                1. Your team or project or whole company should have a work agreement about how bugs are handled.  There should be a way to publish them, a way to prioritize them and a way to schedule them to be fixed.  We strive to follow these rules:

                - A bug found is fixed immediately if it is needed to finish a story in the current sprint.  This is because a story is not considered Done if there are any bugs open against the story.
                - A bug that takes longer than one day to fix is published in the bug tracking system and reported at the Daily Scrum meeting.
                - A bug found that is not blocking a current story is published in the bug tracking system.
                - All open bugs are reviewed once a Sprint to understand priority and schedule them for correction.
                -- If it takes too long to review all the bugs, you have too many open, find out why so many and correct.
                - Bugs are scheduled into the Product Backlog during grooming along with the new features.
                - Bugs are not closed, meaning not considered done, until automated tests are written, shown to find the bug and incorporated into the test suite.

                Now, I subscribe to the idea that tracking bugs is waste and a bug found should be fixed immediately.  This is not always accepted by other members of the Scrum Team so, the above is our current state.

                2. The Sprint Backlog is the list of stories or features that are committed to be completed by the end of the Sprint.  The tasks required to complete a given story are not as important as getting the story done.  Therefore, if a task needs to be divided, divide it.  If some tasks are not needed to finish a story, get rid of them.  Tasks can come and go as long as the story gets done.  Tasks are there to help the team estimate the size of the story and to track story progress to Done.  Divide and combine tasks in ways that help you see when something goes wrong but don't spend too much time working on defining tasks beyond providing the needed visibility of progress or problems.

                2a. If it is found that the story is too big for the Sprint, time to involve the Product Owner to discuss what will be not done by the end of the Sprint.

                Does that help?

                Alan

                On Tue, May 4, 2010 at 5:43 PM, Rafael Nascimento <rafaelnascimento. rj@gmail. com> wrote:
                 

                Hi friends!

                I'm a newbie CSM in a big brazillian project and I have 2 huge doubts:

                1. How do you usually bug track in a sprint? These found bugs are resolved during the actual sprint or they become new stories to be prioritized in the next sprint? And, if it is resolved in the actual sprint, what about the time estimate issue about this "new" task?

                2. How do you often divide your oversized tasks when you discover that it needs to be divided during its development?

                Thanks in advance!

                Best regards!
                Rafael Nascimento





                Looking for a hot date? View photos of singles in your area!
              • Paul Hudson
                ... However, an alternate view A bug means one or more user stories will not be working right. If they re stories from the current sprint, the PO has agreed
                Message 7 of 19 , May 10, 2010
                • 0 Attachment
                  On 10 May 2010 06:53, Roy Morien <roymorien@...> wrote:
                   

                  I find it hard to understand why tracking bugs is not considered a waste, and why the Scrum team does not accept fixing bugs immediately. Accumulating bugs can surely have a detrimental affect on further development.


                  However, an alternate view 

                  A bug means one or more user stories will not be working right. If they're stories from the current sprint, the PO has agreed that those stories are the highest priority right now and so fixing the bugs immediately is the Right Thing to do.

                  If the impacted stories are some pre-existing ones, then getting those fully working may or may not be higher priority than the stories of the current script. Especially since presumably those other stories were at some point considered Done and working...  So it may make sense to put those fixes on the Product Backlog, instead.

                  So if a bug is discovered or reported impacting stories other than those in the current sprint, I think the PO should be involved in the discussion of whether they should be immediately fixed, in the interests of delivering maximum value to the business.

                  Sometimes I think there's no such thing as a bug, just a failure of the software to comply with how it is desired it should work, which might be because it's missing a feature or because there's a defect. What's needed is a change in how the software works - whether you classify the driver for that change as a bug or a feature often doesn't seem very interesting.

                  What have I missed?


                  Paul.
                • Roy Morien
                  Yes, basically you are repeating what I said, with extras. I m not totally sure that you are indeed provifing an alternative view. So it may make sense to
                  Message 8 of 19 , May 10, 2010
                  • 0 Attachment
                    Yes, basically you are repeating what I said, with extras. I'm not totally sure that you are indeed provifing an alternative view.
                     
                    " So it may make sense to put those fixes on the Product Backlog, instead."  You are clearly talking about 'fixes' of previously DONE stories, which makes them not bugs, in my book. They are extras, discovered through usage. Someone has learned something that was not understood or realised previously. These are not bugs, so quite rightly should be put on the Product Backlog and prioritised by the PO.
                     
                    I would change a sentence in this email to read "A bug means one or more user stories are not working right according to the agreed definition of DONE when the functionality was delivered" thus this does imply a bug, and not new information or new requirements.  This situation implies that functionality was delivered with bugs still in it! That should not have happened! But, given that it did happen, I guess the affect of that must be evaluated and action taken in an appropriate timeframe.
                     
                    I think this sort of discussion does go back, in my view, a long way in time, when the definition of what is a bug was first discussed. 'Bug' implies error, omission, faulty code, not new knowledge that may affect previously satisfactorilly completed work.
                     
                    Regards,
                    Roy Morien
                     

                     

                    To: scrumdevelopment@yahoogroups.com
                    From: phudson@...
                    Date: Mon, 10 May 2010 09:54:48 +0100
                    Subject: Re: [scrumdevelopment] Bug tracking and big tasks

                     

                    On 10 May 2010 06:53, Roy Morien <roymorien@hotmail. com> wrote:
                     

                    I find it hard to understand why tracking bugs is not considered a waste, and why the Scrum team does not accept fixing bugs immediately. Accumulating  bugs can surely have a detrimental affect on further development.


                    However, an alternate view 

                    A bug means one or more user stories will not be working right. If they're stories from the current sprint, the PO has agreed that those stories are the highest priority right now and so fixing the bugs immediately is the Right Thing to do.

                    If the impacted stories are some pre-existing ones, then getting those fully working may or may not be higher priority than the stories of the current script. Especially since presumably those other stories were at some point considered Done and working...  So it may make sense to put those fixes on the Product Backlog, instead.

                    So if a bug is discovered or reported impacting stories other than those in the current sprint, I think the PO should be involved in the discussion of whether they should be immediately fixed, in the interests of delivering maximum value to the business.

                    Sometimes I think there's no such thing as a bug, just a failure of the software to comply with how it is desired it should work, which might be because it's missing a feature or because there's a defect. What's needed is a change in how the software works - whether you classify the driver for that change as a bug or a feature often doesn't seem very interesting.

                    What have I missed?


                    Paul.



                    Looking for a hot date? View photos of singles in your area!
                  • Roy Morien
                    oh, one more comment ... I think that it IS interesting especially when you are trying to evaluate the effectivenes of your development method. Having bugs
                    Message 9 of 19 , May 10, 2010
                    • 0 Attachment
                      oh, one more comment ... I think that it IS interesting especially when you are trying to evaluate the effectivenes of your development method. Having 'bugs' tells you something is wrong ... having new requirements that may affect the working of previously satisfactory functionality may very well tell you something is working well. That IS interesting!
                       

                      To: scrumdevelopment@yahoogroups.com
                      From: phudson@...
                      Date: Mon, 10 May 2010 09:54:48 +0100
                      Subject: Re: [scrumdevelopment] Bug tracking and big tasks

                       

                      On 10 May 2010 06:53, Roy Morien <roymorien@hotmail. com> wrote:
                       

                      I find it hard to understand why tracking bugs is not considered a waste, and why the Scrum team does not accept fixing bugs immediately. Accumulating  bugs can surely have a detrimental affect on further development.


                      However, an alternate view 

                      A bug means one or more user stories will not be working right. If they're stories from the current sprint, the PO has agreed that those stories are the highest priority right now and so fixing the bugs immediately is the Right Thing to do.

                      If the impacted stories are some pre-existing ones, then getting those fully working may or may not be higher priority than the stories of the current script. Especially since presumably those other stories were at some point considered Done and working...  So it may make sense to put those fixes on the Product Backlog, instead.

                      So if a bug is discovered or reported impacting stories other than those in the current sprint, I think the PO should be involved in the discussion of whether they should be immediately fixed, in the interests of delivering maximum value to the business.

                      Sometimes I think there's no such thing as a bug, just a failure of the software to comply with how it is desired it should work, which might be because it's missing a feature or because there's a defect. What's needed is a change in how the software works - whether you classify the driver for that change as a bug or a feature often doesn't seem very interesting.

                      What have I missed?


                      Paul.



                      Australia's #1 job site If It Exists, You'll Find it on SEEK
                    • Paul Hudson
                      ... instead. You are clearly talking about fixes of previously DONE stories, which makes them not bugs, in my book. They are extras, discovered through
                      Message 10 of 19 , May 10, 2010
                      • 0 Attachment
                         " So it may make sense to put those fixes on the Product Backlog, instead."  You are clearly talking about 'fixes' of previously DONE stories, which makes them not bugs, in my book. They are extras, discovered through usage

                        Or we may have done an inadequate job of testing the first time around. That would be a bug?

                      • Ron Jeffries
                        ... Yes ... depending on the defect. Sometimes implementing a new story breaks a prior one badly. That s why automated acceptance checks are so important. ...
                        Message 11 of 19 , May 10, 2010
                        • 0 Attachment
                          Hello, Paul. On Monday, May 10, 2010, at 4:54:48 AM, you wrote:

                          > A bug means one or more user stories will not be working right. If they're
                          > stories from the current sprint, the PO has agreed that those stories are
                          > the highest priority right now and so fixing the bugs immediately is the
                          > Right Thing to do.

                          > If the impacted stories are some pre-existing ones, then getting those fully
                          > working may or may not be higher priority than the stories of the current
                          > script. Especially since presumably those other stories were at some point
                          > considered Done and working... So it may make sense to put those fixes on
                          > the Product Backlog, instead.

                          Yes ... depending on the defect. Sometimes implementing a new story
                          breaks a prior one badly. That's why automated acceptance checks are
                          so important.

                          > So if a bug is discovered or reported impacting stories other than those in
                          > the current sprint, I think the PO should be involved in the discussion of
                          > whether they should be immediately fixed, in the interests of delivering
                          > maximum value to the business.

                          Certainly. All work belongs to the PO. All == All.

                          > Sometimes I think there's no such thing as a bug, just a failure of the
                          > software to comply with how it is desired it should work, which might be
                          > because it's missing a feature or because there's a defect. What's needed is
                          > a change in how the software works - whether you classify the driver for
                          > that change as a bug or a feature often doesn't seem very interesting.

                          A defect fix is a story. Sure, why not?

                          Ron Jeffries
                          www.XProgramming.com
                          www.xprogramming.com/blog
                          It's easier to act your way into a new way of thinking
                          than to think your way into a new way of acting. --Millard Fuller
                        • Ron Jeffries
                          ... Not every truth in the world is a rephrasing of what has already been said ... ... Not necessarily new information. The story might be Print the sum of A
                          Message 12 of 19 , May 10, 2010
                          • 0 Attachment
                            Hello, Roy. On Monday, May 10, 2010, at 5:08:23 AM, you wrote:

                            > Yes, basically you are repeating what I said, with extras. I'm
                            > not totally sure that you are indeed provifing an alternative view.

                            Not every truth in the world is a rephrasing of what has already
                            been said ...

                            > " So it may make sense to put those fixes on the Product Backlog,
                            > instead." You are clearly talking about 'fixes' of previously DONE
                            > stories, which makes them not bugs, in my book. They are extras,
                            > discovered through usage. Someone has learned something that was
                            > not understood or realised previously. These are not bugs, so
                            > quite rightly should be put on the Product Backlog and prioritised
                            > by the PO.

                            Not necessarily new information. The story might be "Print the sum
                            of A and B". We might have tested many cases, then later discover
                            that for some reason 2 plus 3 prints as 7. This is clearly a defect.

                            > I would change a sentence in this email to read "A bug means one
                            > or more user stories are not working right according to the agreed
                            > definition of DONE when the functionality was delivered" thus this
                            > does imply a bug, and not new information or new requirements.
                            > This situation implies that functionality was delivered with bugs
                            > still in it! That should not have happened! But, given that it did
                            > happen, I guess the affect of that must be evaluated and action
                            > taken in an appropriate timeframe.

                            Well, yes. Whether the defect is a mistake from the past, an
                            implementation change, a discovery of a missing test, or an
                            oversight by some viewer of the system, the effect is always the
                            same:

                            If you want it fixed, put it on a Sprint Backlog. Or, in modern
                            terms, write a story.

                            > I think this sort of discussion does go back, in my view, a long
                            > way in time, when the definition of what is a bug was first
                            > discussed. 'Bug' implies error, omission, faulty code, not new
                            > knowledge that may affect previously satisfactorilly completed work.

                            A bug is a colloquial term for an insect. Technically speaking, a
                            bug is a particular kind of insect having thickened wings at the
                            base of the wing.

                            A defect is something about the system that we do not like. (Cf.
                            Pirsig: "Quality is what you like.")

                            The causes of defects are interesting when one plans to improve the
                            process. Trying to improve the people's ability not to create
                            defects is fraught, since people improve slowly and only up to some
                            limits. Improving the process works better. One well-known approach
                            is to automate checks for the functionality one cares about.

                            It is wise, in my opinion, to have the checks first, and not to
                            release features until the checks all say "OK". Once a team gets
                            good at this, it seems to be quite straightforward to proceed
                            forward without a lot of debate over which defects to fix and which
                            not to. One just makes sure that there are no broken checks.

                            Once in a while, the team forgets to provide a particular check (or
                            class of checks) and defects ("what you don't like") appear in the
                            code. At this point, schedule the fix and do it. This consists of
                            writing one or more automated checks, and then making all the checks
                            in the system work. Then one reviews how this check (or class of
                            check) got missed out, and improves the process to make it less
                            likely.

                            Ron Jeffries
                            www.XProgramming.com
                            www.xprogramming.com/blog
                            The work teaches us. -- Richard Gabriel
                          • Ron Jeffries
                            ... No. That would be a mistake. :) Ron Jeffries www.XProgramming.com www.xprogramming.com/blog He who will not apply new remedies must expect old evils. --
                            Message 13 of 19 , May 10, 2010
                            • 0 Attachment
                              Hello, Paul. On Monday, May 10, 2010, at 5:30:03 AM, you wrote:

                              >> " So it may make sense to put those fixes on the Product Backlog,
                              > instead." You are clearly talking about 'fixes' of previously DONE stories,
                              > which makes them not bugs, in my book. They are extras, discovered through
                              > usage

                              > Or we may have done an inadequate job of testing the first time around. That
                              > would be a bug?

                              No. That would be a mistake. :)

                              Ron Jeffries
                              www.XProgramming.com
                              www.xprogramming.com/blog
                              He who will not apply new remedies must expect old evils. -- Francis Bacon
                            Your message has been successfully submitted and would be delivered to recipients shortly.