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

Re: [scrumdevelopment] Bug tracking and big tasks

Expand Messages
  • Ken Schwaber
    Come to the famed Brazilian Scrum day on July 24 and find out!! Ken
    Message 1 of 19 , May 4 7:05 PM
    • 0 Attachment
      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


    • Alan Dayley
      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
      Message 2 of 19 , May 4 7:13 PM
      • 0 Attachment
        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


      • JackM
        Ideally you want to fix as many bugs as you can in the same sprint that you find them. That should be your definition of done. This is really quite hard to do
        Message 3 of 19 , May 4 8:07 PM
        • 0 Attachment
          Ideally you want to fix as many bugs as you can in the same sprint that you find them. That should be your definition of done. This is really quite hard to do at first and you need a lot of discipline and of course you need to involve qa early. In terms of tracking the bugs there are many ways to do this. I prefer not to track these on the backlog i.e. the team has to consume bugs as part of doing business. Overall this will impact your velocity but that's ok On average it should all work out in the end.

          Track the bugs in a bug tracker if you have to. If you're working with a Scrum board you can add the bugs to the scrum board - so that everyone knows what you're working on.

          If you want you can actually estimate the size of the bugs and track them but I personally wouldn't recommend this approach.

          Breaking downs tasks or even stories is hard at first too. It's important to keep the stories and tasks as small as possible

          Hope this helps you

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

          --- In scrumdevelopment@yahoogroups.com, 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
          Yeah Jack, you really helped me. Thanks! If anyone else would like to share experiences about these itens I´ve pointed, I ll be glad! 2010/5/5 JackM
          Message 4 of 19 , May 5 6:50 AM
          • 0 Attachment
            Yeah Jack, you really helped me. Thanks!
            If anyone else would like to share experiences about these itens I´ve pointed, I'll be glad!

            2010/5/5 JackM <jack@...>
             

            Ideally you want to fix as many bugs as you can in the same sprint that you find them. That should be your definition of done. This is really quite hard to do at first and you need a lot of discipline and of course you need to involve qa early. In terms of tracking the bugs there are many ways to do this. I prefer not to track these on the backlog i.e. the team has to consume bugs as part of doing business. Overall this will impact your velocity but that's ok On average it should all work out in the end.

            Track the bugs in a bug tracker if you have to. If you're working with a Scrum board you can add the bugs to the scrum board - so that everyone knows what you're working on.

            If you want you can actually estimate the size of the bugs and track them but I personally wouldn't recommend this approach.

            Breaking downs tasks or even stories is hard at first too. It's important to keep the stories and tasks as small as possible

            Hope this helps you

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



            --- In scrumdevelopment@yahoogroups.com, 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
            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
            Message 5 of 19 , May 5 6:55 AM
            • 0 Attachment
              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



            • 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 6 of 19 , May 5 7:04 AM
              • 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 7 of 19 , May 5 7:07 AM
                • 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 8 of 19 , May 5 11:11 AM
                  • 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 9 of 19 , May 5 11:51 AM
                    • 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 10 of 19 , May 5 12:52 PM
                      • 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 11 of 19 , May 9 10:53 PM
                        • 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 12 of 19 , May 10 1:54 AM
                          • 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 13 of 19 , May 10 2:08 AM
                            • 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 14 of 19 , May 10 2:10 AM
                              • 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 15 of 19 , May 10 2:30 AM
                                • 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 16 of 19 , May 10 3:05 AM
                                  • 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 17 of 19 , May 10 3:18 AM
                                    • 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 18 of 19 , May 10 3:19 AM
                                      • 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.