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

Re: [scrumdevelopment] Re: accounting for bugs

Expand Messages
  • Charles Bradley - Scrum Coach CSM PSM I
    Peter, ... Something as simple as changing a value in a configuration file can result in an immediate, significant loss of revenue. In that case, I d prefer a
    Message 1 of 35 , Apr 20, 2012
    • 0 Attachment
      Peter,

      > An alternative definition of Trivial: If it is more work to discuss it than to do it, it is trivial. Just do it!
      Something as simple as changing a value in a configuration file can result in an immediate, significant loss of revenue.

      In that case, I'd prefer a discussion that might take longer than the time to "just do it."

      For that reason, I'm more in line with Dave's thinking -- trivial refers to the time it takes to "do it", not the time it takes to have a discussion on whether it should be done or not.

      I do think I understand the theme of what you're saying, though -- that we should not get involved in "analysis paralysis" or "low value discussions."
       
      -------
      Charles Bradley
      http://www.ScrumCrazy.com




      From: Peter Stevens <peterstev@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Friday, April 20, 2012 5:46 AM
      Subject: Re: [scrumdevelopment] Re: accounting for bugs



      An alternative definition of Trivial: If it is more work to discuss it than to do it, it is trivial. Just do it!

      On 19.04.12 12:40, Chuck B wrote:
       
      I like your strategy, Dave.

      I agree on the "trivial" definition concept.  I use the term "material" instead (Shape#2).  IMO, I don't like either term very much.  "Material/Immaterial" is not a concept that anyone outside of accounting inherently understands.  IMO, "trivial" makes the issue sound like we shouldn't even bother addressing it since it's "trivial," when this is often not true.  OTOH, "Not worth tracking" is a bit too wordy and also makes the issue sound like it's not worth addressing.  I'm still searching for better terminology there, but have yet to come up with much.

      Are Story points at all a part of your strategy?  Do you make a distinction between something that is a bug, something that is  Prod Support time, and something that is a new requirement? 
       
      -------
      Charles Bradley
      http://www.ScrumCrazy.com




      From: David A Barrett <dave.barrett@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Thursday, April 19, 2012 10:13 AM
      Subject: [scrumdevelopment] Re: accounting for bugs



      Charles,

      We have a much simpler process:

      1.  Is it trivial?  Then do it now.

      otherwise:

      2.  Is it important?  If not, then handle it as scheduled work.
      3.  Is it urgent?  If not, then handle it as scheduled work.

      So the only non-trivial unscheduled work that gets done has to be both important and urgent.  This doesn't have to be just bugs. It could be anything that comes up in terms of maintenance and support.  We see lots of requests for ad-hoc reports, and fixing user errors.

      You have to set a definition of "trivial".  I'd say anything less than 30 minutes is trivial, unless this still allows enough stuff to distract the Team to be a problem.  In that case, make the time cutoff smaller.

      There are lots of things that come up that are important but not urgent, or visa versa.  For instance, a problem found in a year-end report may be really important, but if year-end is 11 months away it's probably not going to be urgent.  The same problem might actually arise at year end, but the finance guys may be willing to manually account for it - in which case it has urgency but very little importance.  




      Dave Barrett


      This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately.

      Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez le supprimer et m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.






      -- 
      Peter Stevens, Scrum Trainer & Coach
      blog:          http://scrum-breakfast.com
      




    • Charles Bradley - Scrum Coach CSM PSM I
      Peter, ... Something as simple as changing a value in a configuration file can result in an immediate, significant loss of revenue. In that case, I d prefer a
      Message 35 of 35 , Apr 20, 2012
      • 0 Attachment
        Peter,

        > An alternative definition of Trivial: If it is more work to discuss it than to do it, it is trivial. Just do it!
        Something as simple as changing a value in a configuration file can result in an immediate, significant loss of revenue.

        In that case, I'd prefer a discussion that might take longer than the time to "just do it."

        For that reason, I'm more in line with Dave's thinking -- trivial refers to the time it takes to "do it", not the time it takes to have a discussion on whether it should be done or not.

        I do think I understand the theme of what you're saying, though -- that we should not get involved in "analysis paralysis" or "low value discussions."
         
        -------
        Charles Bradley
        http://www.ScrumCrazy.com




        From: Peter Stevens <peterstev@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Friday, April 20, 2012 5:46 AM
        Subject: Re: [scrumdevelopment] Re: accounting for bugs



        An alternative definition of Trivial: If it is more work to discuss it than to do it, it is trivial. Just do it!

        On 19.04.12 12:40, Chuck B wrote:
         
        I like your strategy, Dave.

        I agree on the "trivial" definition concept.  I use the term "material" instead (Shape#2).  IMO, I don't like either term very much.  "Material/Immaterial" is not a concept that anyone outside of accounting inherently understands.  IMO, "trivial" makes the issue sound like we shouldn't even bother addressing it since it's "trivial," when this is often not true.  OTOH, "Not worth tracking" is a bit too wordy and also makes the issue sound like it's not worth addressing.  I'm still searching for better terminology there, but have yet to come up with much.

        Are Story points at all a part of your strategy?  Do you make a distinction between something that is a bug, something that is  Prod Support time, and something that is a new requirement? 
         
        -------
        Charles Bradley
        http://www.ScrumCrazy.com




        From: David A Barrett <dave.barrett@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Thursday, April 19, 2012 10:13 AM
        Subject: [scrumdevelopment] Re: accounting for bugs



        Charles,

        We have a much simpler process:

        1.  Is it trivial?  Then do it now.

        otherwise:

        2.  Is it important?  If not, then handle it as scheduled work.
        3.  Is it urgent?  If not, then handle it as scheduled work.

        So the only non-trivial unscheduled work that gets done has to be both important and urgent.  This doesn't have to be just bugs. It could be anything that comes up in terms of maintenance and support.  We see lots of requests for ad-hoc reports, and fixing user errors.

        You have to set a definition of "trivial".  I'd say anything less than 30 minutes is trivial, unless this still allows enough stuff to distract the Team to be a problem.  In that case, make the time cutoff smaller.

        There are lots of things that come up that are important but not urgent, or visa versa.  For instance, a problem found in a year-end report may be really important, but if year-end is 11 months away it's probably not going to be urgent.  The same problem might actually arise at year end, but the finance guys may be willing to manually account for it - in which case it has urgency but very little importance.  




        Dave Barrett


        This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately.

        Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez le supprimer et m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.






        -- 
        Peter Stevens, Scrum Trainer & Coach
        blog:          http://scrum-breakfast.com
        




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