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

Re: How to cope with bugs ?

Expand Messages
  • bkantelis
    ... It is about developing a system and a culture. We categorize defects. Priority 1, blocking the user from working get immediate attention, the interrupt
    Message 1 of 23 , Jul 10, 2009
      --- In scrumdevelopment@yahoogroups.com, Jim Schiel <schiel@...> wrote:
      >
      > I don't know that you really need to create user stories for defects.
      > You can, however, put the defect on the backlog for it to be
      > prioritized by the Product Owner. Almost the same thing, but simpler.
      > You can groom the defect into a solution during the preceding Sprint
      > -- unless its a dead simple fix, in which case you determine the
      > solution during Sprint Planning and execute the solution during the
      > Sprint.
      >
      > Jim Schiel, CST
      > Artisan Software Consulting
      >

      It is about developing a system and a culture. We categorize defects. Priority 1, blocking the user from working get immediate attention, the interrupt work for a fix and patch, all others become stories that are placed at the top of the list for the next sprint. Over time, teams realize that quality measures and behaviors really impact their workday and rally to minimize the interruption.
      Regards,
      Bruce
    • Kevlin Henney
      ... This is an interesting approach: it is essentially an unfair scheduling algorithm in which it is not bug fixing that gets constrained and starved, but new
      Message 2 of 23 , Jul 10, 2009
        2009/7/10 bkantelis <bkantelis@...>:
        >
        > It is about developing a system and a culture. We categorize defects.
        > Priority 1, blocking the user from working get immediate attention, the
        > interrupt work for a fix and patch, all others become stories that are
        > placed at the top of the list for the next sprint. Over time, teams realize
        > that quality measures and behaviors really impact their workday and rally to
        > minimize the interruption.

        This is an interesting approach: it is essentially an unfair
        scheduling algorithm in which it is not bug fixing that gets
        constrained and starved, but new feature development. It makes quality
        problems properly visible in a way that invites -- in fact, demands --
        attention. Nice one.

        Kevlin
        --
        ________________________

        Kevlin Henney
        +44 7801 073 508
        http://curbralan.com
        http://kevlin.tel
        ________________________
      • Ron Jeffries
        ... I see now why people think the world is unfair. Ron Jeffries www.XProgramming.com www.xprogramming.com/blog Do only what is necessary. Keep only what you
        Message 3 of 23 , Jul 10, 2009
          Hello, Kevlin. On Friday, July 10, 2009, at 5:33:01 AM, you wrote:

          >> I understand your point here about 'unfair scheduling' of bugs. I don't
          >> agree though. If a bug is waiting to be fixed for a long time due to having
          >> a lower priority, this is fair.

          > Just to clarify, if something never happens because there is always
          > something at a higher priority, this is technically known as an unfair
          > scheduling algorithm. This is a matter of definition rather than a
          > matter of opinion. So, the question is not whether or not it is
          > unfair, but whether or not it is appropriate.

          I see now why people think the world is unfair.

          Ron Jeffries
          www.XProgramming.com
          www.xprogramming.com/blog
          Do only what is necessary. Keep only what you need.
        • Ron Jeffries
          Hello, bkantelis. On Friday, July 10, 2009, at 7:48:12 AM, you ... Is that working? What have the teams done? Ron Jeffries www.XProgramming.com
          Message 4 of 23 , Jul 10, 2009
            Hello, bkantelis. On Friday, July 10, 2009, at 7:48:12 AM, you
            wrote:

            > It is about developing a system and a culture. We categorize
            > defects. Priority 1, blocking the user from working get immediate
            > attention, the interrupt work for a fix and patch, all others
            > become stories that are placed at the top of the list for the next
            > sprint. Over time, teams realize that quality measures and
            > behaviors really impact their workday and rally to minimize the interruption.

            Is that working? What have the teams done?

            Ron Jeffries
            www.XProgramming.com
            www.xprogramming.com/blog
            Q: How do we get to Aspen?
            A: Climb to the top of that hill.
            Q: That is so dumb: Aspen is in a valley.
            A: OK.
          • Ron Jeffries
            Hello, Pascal. On Thursday, July 9, 2009, at 5:11:44 PM, you ... With respect to Kevlin, a defect /is/ a negative feature. More interestingly, it is
            Message 5 of 23 , Jul 10, 2009
              Hello, Pascal. On Thursday, July 9, 2009, at 5:11:44 PM, you
              wrote:

              > So should I create user stories for bug fixing ?
              > I don't like the idea of a sprint dedicated to bug fixing, so maybe a mix of
              > feature development and bug fixing is a good practice ?

              With respect to Kevlin, a defect /is/ a negative feature. More
              interestingly, it is disproportionately negative.

              I would define the cost K of a feature as the cost of implementing
              it "right the first time," that is, implementing the feature such
              that no defects are found in it down stream.

              If we put a defect into the feature, it may cost more, or less, or
              the same up to the release of the feature. Generally, it's about the
              same.

              So now we have a story that has cost about K, and it does not work.
              There is a defect. To fix that defect will cost something. Let's
              call that additional cost d. So implementing the feature with a
              defect in it, and then removing it, will cost K + d. For all
              positive d, K+d > K, that is, it //always// costs more to build a
              feature incorrectly and then fix it.

              So when we write the software incorrectly and then fix it, the
              customer pays more: she pays whatever she paid before, plus the bug
              fixing penalty.

              She should be really ticked off about that. I like to encourage the
              customer to prioritize all the defects, to ensure that she'll feel
              the pain of the team's inadequate software process. I feel sure that
              she'll express that pain and that the team has a better chance of
              getting the idea that doing things well is better.

              Ron Jeffries
              www.XProgramming.com
              www.xprogramming.com/blog
              Confidence has nothing to do with perfection.
              It has to do with a quality of deep self-acceptance
              that leads us to do things in a masterful way,
              as it allows us to speak our mind and our hearts. -- Agapi Stassinopoulos
            • Vercauteren Tom
              What we do with bugs is this: Most bugs are logged during the same sprint that the user story is developed. We KNOW there will be bugs in what is created
              Message 6 of 23 , Jul 14, 2009
                What we do with bugs is this:
                Most bugs are logged during the same sprint that the user story is developed.  We KNOW there will be bugs in what is created (even our developers admit this!) so we add about 15% of blanc "tasks" on the sprint burndown.  As bugs are found, the team decides:
                - fill in one of these "tasks" (if we run out of blanc notes, we add new tasks, causing the burn down to go up)
                - add them to the product backlog "for later fixing".  The product owner should give them a business value.
                - discard them, because they are "not really a bug".
                 
                Usually, the last user story that is being developed, can't be tested any more.  We TRY to stop development a few days before the sprint ends, and have our developers write documentation and such, but in reality we all know that the final user story is developed the day the sprint ends. 
                As this user story is not done, all remaining tasks (including testing and bugfixing) will be taken to the next sprint.
                 

                regards,
                Tom

                A-functional-tester-on-a-scrum-team

                 


                Van: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] Namens Ron Jeffries
                Verzonden: vrijdag 10 juli 2009 16:24
                Aan: scrumdevelopment@yahoogroups.com
                Onderwerp: Re: [scrumdevelopment] How to cope with bugs ?

                Hello, Pascal. On Thursday, July 9, 2009, at 5:11:44 PM, you
                wrote:

                > So should I create user stories for bug fixing
                ?
                > I don't like the idea of a sprint dedicated to bug fixing, so maybe a
                mix of
                > feature development and bug fixing is a good practice
                ?

                With respect to Kevlin, a defect /is/ a negative feature. More
                interestingly, it is disproportionately negative.

                I would define the cost K of a feature as the cost of implementing
                it "right the first time," that is, implementing the feature such
                that no defects are found in it down stream.

                If we put a defect into the feature, it may cost more, or less, or
                the same up to the release of the feature. Generally, it's about the
                same.

                So now we have a story that has cost about K, and it does not work.
                There is a defect. To fix that defect will cost something. Let's
                call that additional cost d. So implementing the feature with a
                defect in it, and then removing it, will cost K + d. For all
                positive d, K+d > K, that is, it //always// costs more to build a
                feature incorrectly and then fix it.

                So when we write the software incorrectly and then fix it, the
                customer pays more: she pays whatever she paid before, plus the bug
                fixing penalty.

                She should be really ticked off about that. I like to encourage the
                customer to prioritize all the defects, to ensure that she'll feel
                the pain of the team's inadequate software process. I feel sure that
                she'll express that pain and that the team has a better chance of
                getting the idea that doing things well is better.

                Ron Jeffries
                www.XProgramming. com
                www.xprogramming. com/blog
                Confidence has nothing to do with perfection.
                It has to do with a quality of deep self-acceptance
                that leads us to do things in a masterful way,
                as it allows us to speak our mind and our hearts. -- Agapi Stassinopoulos

                This message is explicitly subject to the conditions of the e-mail disclaimer: www.sdworx.com/emaildisclaimer 
                If you are unable to consult this e-mail disclaimer, please notify the sender at once.
              • Ron Jeffries
                Hello, Tom. On Tuesday, July 14, 2009, at 10:38:54 AM, ... It seems to me that you are describing the effect of impediments that need to be removed. Does it
                Message 7 of 23 , Jul 14, 2009
                  Hello, Tom. On Tuesday, July 14, 2009, at 10:38:54 AM,
                  you wrote:

                  > What we do with bugs is this:
                  > Most bugs are logged during the same sprint that the user story
                  > is developed. We KNOW there will be bugs in what is created (even
                  > our developers admit this!) so we add about 15% of blanc "tasks"
                  > on the sprint burndown. As bugs are found, the team decides:
                  > - fill in one of these "tasks" (if we run out of blanc notes, we
                  > add new tasks, causing the burn down to go up)
                  > - add them to the product backlog "for later fixing". The
                  > product owner should give them a business value.
                  > - discard them, because they are "not really a bug".

                  > Usually, the last user story that is being developed, can't be
                  > tested any more. We TRY to stop development a few days before the
                  > sprint ends, and have our developers write documentation and such,
                  > but in reality we all know that the final user story is developed
                  > the day the sprint ends. As this user story is not done, all
                  > remaining tasks (including testing and bugfixing) will be taken to
                  > the next sprint.

                  It seems to me that you are describing the effect of impediments
                  that need to be removed. Does it seem that way to you?

                  Ron Jeffries
                  www.XProgramming.com
                  www.xprogramming.com/blog
                  Master your instrument, master the music,
                  and then forget all that *!xy!@ and just play. -- Charlie Parker
                • Mark Levison
                  Questions of when to fix them aside - I would start to ask the question why weren t they found and fixed within the sprint that they occured? My focus is on
                  Message 8 of 23 , Jul 15, 2009
                    Questions of when to fix them aside - I would start to ask the question why weren't they found and fixed within the sprint that they occured? My focus is on reducing the time it takes to discover (and then fix) problems. After all if we discover a bug in the story during the sprint it is written then the PO shoudl accept it as being done. In addition early discovery will make it much easier to fix as the code is still fresh in the mind of the development team.

                    Cheers
                    Mark

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




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

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

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

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

                      All your points are valid - thanks

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

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

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

                        Cheers
                        Mark

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

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

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

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

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

                        All your points are valid - thanks

                        www.agilebuddy.com


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

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



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

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

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

                          Just my two cents,

                          Juan

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

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


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

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

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

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

                              Just my two cents,

                              Juan

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




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

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

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

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

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

                                Cheers
                                Mark



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

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

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

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

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

                                All your points are valid - thanks

                                www.agilebuddy.com


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

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



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

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