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

Re: [scrumdevelopment] How to cope with bugs ?

Expand Messages
  • George Dinwiddie
    ... A good topic for the team during retrospectives. I ve seen teams with vanishingly small bug rates. ... I think that s a good idea. ... I would let the
    Message 1 of 23 , Jul 9, 2009
    • 0 Attachment
      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
      ----------------------------------------------------------------------
    • Jim Schiel
      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
      Message 2 of 23 , Jul 9, 2009
      • 0 Attachment
        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
        ------------ --------- --------- --------- --------- --------- -


      • jmilunsky
        This should help you http://blog.mountaingoatsoftware.com/bugs-on-the-product-backlog
        Message 3 of 23 , Jul 9, 2009
        • 0 Attachment
          This should help you

          http://blog.mountaingoatsoftware.com/bugs-on-the-product-backlog


          --- In scrumdevelopment@yahoogroups.com, Pascal Maugeri <pascal.maugeri@...> wrote:
          >
          > Hi
          >
          > So far we haven't found the way to make bug-free software in my company :-)
          >
          > So team members are asking me where to put work effort for fixing bugs found
          > in previous sprints. I'm taking over the role of scrum master in this
          > project...
          >
          > 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.
          >
          > 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 ?
          >
          > Thanks in advance for your inputs
          > Pascal
          >
        • jmilunsky
          This should help you http://blog.mountaingoatsoftware.com/bugs-on-the-product-backlog Jack twitter.com/agilebuddy blog.agilebuddy.com
          Message 4 of 23 , Jul 9, 2009
          • 0 Attachment
            This should help you

            http://blog.mountaingoatsoftware.com/bugs-on-the-product-backlog

            Jack
            twitter.com/agilebuddy
            blog.agilebuddy.com


            --- In scrumdevelopment@yahoogroups.com, Pascal Maugeri <pascal.maugeri@...> wrote:
            >
            > Hi
            >
            > So far we haven't found the way to make bug-free software in my company :-)
            >
            > So team members are asking me where to put work effort for fixing bugs found
            > in previous sprints. I'm taking over the role of scrum master in this
            > project...
            >
            > 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.
            >
            > 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 ?
            >
            > Thanks in advance for your inputs
            > Pascal
            >
          • Kevlin Henney
            ... Putting defects in the same backlog as ordinary developed features is something that may work for some teams at some times, but should ultimately be
            Message 5 of 23 , Jul 9, 2009
            • 0 Attachment
              2009/7/10 jmilunsky <jack@...>:
              >
              > This should help you
              >
              > http://blog.mountaingoatsoftware.com/bugs-on-the-product-backlog

              Putting defects in the same backlog as ordinary developed features is
              something that may work for some teams at some times, but should
              ultimately be considered a dysfunctional behaviour that you want to
              eliminate. It may be a useful short-term transition, but if you're on
              that highway you need to know how and when you intend to get off.

              Mixing defects with product features devalues the concept of the
              product backlog, polluting it with items that have no reasonable
              estimation model. It rewards the wrong behaviours and mindset, making
              feature development and defect removal seem equivalent and just
              business as usual. Conventional prioritisation can also lead to the
              problem of unfair scheduling, where bugs of apparently low priority
              languish for months or years, persistently annoying some product users
              at the expense of the big accounts who manage to raise the priority by
              appearing larger on the radar (as happened to a company I visited last
              year).

              The aim is to make defects more visible, but mixing them into the
              normal presentation of the feature set is more likely to have the
              opposite effect. Some separation is necessary to see them properly and
              for what they are.

              I mention this issue in the "Defects vs. value" section near the
              beginning of http://is.gd/1teNp

              Kevlin
            • Jacob Ozolins
              Hello, 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
              Message 6 of 23 , Jul 10, 2009
              • 0 Attachment
                Hello,
                 
                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. Your P.O. should estimate the impact of leaving bugs unfixed, and one of the variables he should consider is how long the bug has been 'hanging around'. As a P.O. myself I am re-evaluating the entire bug backlog whenever I or someone else adds a new item to it. So, if a bug is constantly pushed down the list - that is it's rightful place.
                 
                Our team handles bugs by setting aside a single day per developer per sprint to spend on bug fixing - and I add this as a contingency. Sometimes this time is all used up by the end of the sprint, sometimes it isn't. When it isn't (due to lack of bugs to fix), the developers ultimately have more time for planned stories, and my assumption is that spending more time on them results in better quality code, thus reducing emerging bugs in the future.
                 
                I add only the bugs I want fixed during the current sprint onto the storyboard, and will mention during stand up if I want something fixed immediately (otherwise I don't speak at all - and I don't always attend).
                When there are more bugs than can be handled in this 'reserved' time, I reevaluate the impact on the sprint, and if it looks like we will not meet the goals, I inform the stakeholders and let them decide which to go for; completed stories, or fixed bugs. This is a rarity, however.
                 
                These are just my methods, not my suggestions. But they're working for us.
                 
                Thanks,
                Jacob
                 
                 

                 
                On Fri, Jul 10, 2009 at 9:56 AM, Kevlin Henney <kevlin.henney@...> wrote:


                Conventional prioritisation can also lead to the
                problem of unfair scheduling, where bugs of apparently low priority
                languish for months or years, persistently annoying some product users
                at the expense of the big accounts who manage to raise the priority by
                appearing larger on the radar (as happened to a company I visited last
                year).

                .


              • Kevlin Henney
                ... Just to clarify, if something never happens because there is always something at a higher priority, this is technically known as an unfair scheduling
                Message 7 of 23 , Jul 10, 2009
                • 0 Attachment
                  2009/7/10 Jacob Ozolins <j.ozolins@...>:
                  >
                  > 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.

                  > Your P.O. should estimate the impact of
                  > leaving bugs unfixed, and one of the variables he should consider is how
                  > long the bug has been 'hanging around'. As a P.O. myself I am re-evaluating
                  > the entire bug backlog whenever I or someone else adds a new item to it. So,
                  > if a bug is constantly pushed down the list - that is it's rightful place.

                  What criteria are being used? Simple prioritisation is effective if
                  the work to do is likely to reach zero, i.e., you only ever carry a
                  few defects, otherwise it will lead to unfairness, i.e., some defects
                  are guaranteed to never be addressed because of their low priority. If
                  this limit is exceed, and if prioritisation is based only on something
                  like the value of a particular customer or severity of the defect, a
                  more dynamic view should be taken. For example, include the age of a
                  bug in its priority weighting.

                  > Our team handles bugs by setting aside a single day per developer per sprint
                  > to spend on bug fixing - and I add this as a contingency. Sometimes this
                  > time is all used up by the end of the sprint, sometimes it isn't. When it
                  > isn't (due to lack of bugs to fix), the developers ultimately have more time
                  > for planned stories, and my assumption is that spending more time on them
                  > results in better quality code, thus reducing emerging bugs in the future.

                  From a scheduling point of view, this represents fairness with respect
                  to handling defects as a whole. It is effectively a round-robin
                  approach to ensuring that defects are addressed within each sprint and
                  so are not batched towards the end of development or starved from ever
                  being addressed at all, so that new features always take priority.

                  However, within that scheduling strategy, the way in which defects are
                  fixed is then open to further scheduling, as mentioned above.

                  > I add only the bugs I want fixed during the current sprint onto the
                  > storyboard, and will mention during stand up if I want something fixed
                  > immediately (otherwise I don't speak at all - and I don't always attend).

                  Yes, defect fixing should definitely appear in what you have earmarked
                  for current work, so nothing wrong with putting them in the sprint
                  backlog and on the board.

                  > When there are more bugs than can be handled in this 'reserved' time, I
                  > reevaluate the impact on the sprint, and if it looks like we will not meet
                  > the goals, I inform the stakeholders and let them decide which to go for;
                  > completed stories, or fixed bugs. This is a rarity, however.

                  Seems like a sound strategy.

                  Kevlin
                • 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 8 of 23 , Jul 10, 2009
                  • 0 Attachment
                    --- 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 9 of 23 , Jul 10, 2009
                    • 0 Attachment
                      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 10 of 23 , Jul 10, 2009
                      • 0 Attachment
                        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 11 of 23 , Jul 10, 2009
                        • 0 Attachment
                          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 12 of 23 , Jul 10, 2009
                          • 0 Attachment
                            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 13 of 23 , Jul 14, 2009
                            • 0 Attachment
                              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 14 of 23 , Jul 14, 2009
                              • 0 Attachment
                                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 15 of 23 , Jul 15, 2009
                                • 0 Attachment
                                  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 16 of 23 , Jul 15, 2009
                                  • 0 Attachment
                                    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 17 of 23 , Jul 15, 2009
                                    • 0 Attachment
                                      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 18 of 23 , Jul 16, 2009
                                      • 0 Attachment
                                        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 19 of 23 , Jul 16, 2009
                                        • 0 Attachment
                                          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 20 of 23 , Jul 16, 2009
                                          • 0 Attachment
                                            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 21 of 23 , Jul 16, 2009
                                            • 0 Attachment
                                              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.