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

FW: [object-technology] [Jeff Sutherland's Object Technology Web Site] Project Management: Counting bug inflow and outflow

Expand Messages
  • Ken Schwaber
    Jeff Sutherland found a stealth article by Mike Cohn. It has some really solid thinking about defect metrics. I ve been thinking more about this lately as part
    Message 1 of 2 , Dec 18, 2002
    • 0 Attachment
      Jeff Sutherland found a stealth article by Mike Cohn. It has some really solid thinking about defect metrics. I've been thinking more about this lately as part of the "potentially shippable increment" that is demonstrated at the end of each Sprint. Because the product owner wants to know what is being demonstrated, knowing the solidity and bugginess of the increment is important. Is the product owner seeing something that really is potentially shippable, or does it need two Sprints of testing and debugging first?
       
      As Mike points out, though, measuring defects is tricky. Whenever you measure/observe something, it changes. I remember a problem at Honeywell with their process control computers. The customer engineers were taking too long at customer sites to fix them, and the over CE cost was increasing. So, bonuses were instituted for CE's that reduced "onsite" time fixing the computers. The result? The onsite time went down as the CE's stopped fixing the computers and started doing component swapping, taking out potentially fixable components and replacing them with really expensive new components. Watch out what you ask for, because you might get it.
       
      Ken
       
       
       
      -----Original Message-----
      From: Jeff Sutherland [mailto:jeff.sutherland@...]
      Sent: Monday, December 16, 2002 9:22 AM
      To: object-technology@yahoogroups.com
      Subject: [object-technology] [Jeff Sutherland's Object Technology Web Site] Project Management: Counting bug inflow and outflow


      Cohn, Mike. (2002) "A Measured Reponse: Useful metrics to give managers the numbers to back up project hunches." STQE 4(5):20-25, Sep-Oct.

      A few years ago, I was leading a large development group and the leaders of the Quality Assurance team visited me. They said they were ready to provide me any metrics I wanted. AlI I wanted was bugs found vs. bugs fixed day by day for each product along with cumulative bugs outstanding by day. Looking crestfallen, they asked if that was all.

      That is all I wanted, a simple metric, that turned out to take a lot of work for them to provide it for dozens of products under development. It tells you how much QA work is getting done, how buggy the product is, whether the bugs are overwhelming the ! development team as you approach ship date, and so forth. You can largely predict the success of the rollout of a new product by knowing this single metric.

      There does not seem to be a lot written about this simple metric. I was happy to see Mike Cohn make it the centerpiece of his article. Recommended.

      --
      Posted by Jeff Sutherland to Jeff Sutherland's Object Technology Web Site at 12/13/2002 6:12:32 PM

      Powered by Blogger Pro
      To Post a message, send it to:   object-technology@...

      To Unsubscribe, send a blank message to: object-technology-unsubscribe@...


      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
    • Linda Rising
      Ken, Your Honeywell story is a good one. I have soooooo many like it. Back in the days of heavy-duty causal analysis at one nameless company, we were always
      Message 2 of 2 , Dec 19, 2002
      • 0 Attachment
        Ken,

        Your Honeywell story is a good one. I have soooooo many like it. Back in the days of
        heavy-duty causal analysis at one nameless company, we were always amazed at what
        management had decided to "count" :-)! When there is no trust and no communication,
        the replacement is usually this kind of attempt to control the environment that results in
        exactly the kind of craziness you describe.



        Linda



        Ken Schwaber wrote:
        href=http://jeffsutherland.org/>
        Jeff Sutherland found a stealth article by Mike Cohn. It has some really solid thinking about defect metrics. I've been thinking more about this lately as part of the "potentially shippable increment" that is demonstrated at the end of each Sprint. Because the product owner wants to know what is being demonstrated, knowing the solidity and bugginess of the increment is important. Is the product owner seeing something that really is potentially shippable, or does it need two Sprints of testing and debugging first?
         
        As Mike points out, though, measuring defects is tricky. Whenever you measure/observe something, it changes. I remember a problem at Honeywell with their process control computers. The customer engineers were taking too long at customer sites to fix them, and the over CE cost was increasing. So, bonuses were instituted for CE's that reduced "onsite" time fixing the computers. The result? The onsite time went down as the CE's stopped fixing the computers and started doing component swapping, taking out potentially fixable components and replacing them with really expensive new components. Watch out what you ask for, because you might get it.
         
        Ken
         
         
         
        -----Original Message-----
        From: Jeff Sutherland [mailto:jeff.sutherland@...]
        Sent: Monday, December 16, 2002 9:22 AM
        To: object-technology@yahoogroups.com
        Subject: [object-technology] [Jeff Sutherland's Object Technology Web Site] Project Management: Counting bug inflow and outflow


        Cohn, Mike. (2002) "A Measured Reponse: Useful metrics to give managers the numbers to back up project hunches." STQE 4(5):20-25, Sep-Oct.

        A few years ago, I was leading a large development group and the leaders of the Quality Assurance team visited me. They said they were ready to provide me any metrics I wanted. AlI I wanted was bugs found vs. bugs fixed day by day for each product along with cumulative bugs outstanding by day. Looking crestfallen, they asked if that was all.

        That is all I wanted, a simple metric, that turned out to take a lot of work for them to provide it for dozens of products under development. It tells you how much QA work is getting done, how buggy the product is, whether the bugs are overwhelming the ! development team as you approach ship date, and so forth. You can largely predict the success of the rollout of a new product by knowing this single metric.

        There does not seem to be a lot written about this simple metric. I was happy to see Mike Cohn make it the centerpiece of his article. Recommended.

        --
        Posted by Jeff Sutherland to Jeff Sutherland's Object Technology Web Site at 12/13/2002 6:12:32 PM

        Powered by Blogger Pro
        To Post a message, send it to:   object-technology@...

        To Unsubscribe, send a blank message to: object-technology-unsubscribe@...


        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service .

        To Post a message, send it to:   scrumdevelopment@...
        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service .

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