logo       

FW: [object-technology] [Jeff Sutherland's Object Technology Web Site] Proj: msg#00055

programming.scrum.general

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

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@xxxxxxxxxxxx]
Sent: Monday, December 16, 2002 9:22 AM
To: object-technology@xxxxxxxxxxxxxxx
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@xxxxxxxxxxx

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


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

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


Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise