|
|
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
![]() 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.
|
|
|