Re: [scrumdevelopment] Re: Metrics to report up
- Hello, Doug. On Monday, November 1, 2010, at 4:56:36 AM, you
> After reading thru Alan's response, below, it occurs to me thatNo, no, a thousand times no. Whatever you measure here, even if it
> "most management" will want to have a quantitative, comparative
> sense of teams productivity (so they can determine which teams are
> producing more "business value", with the objective of then trying
> to improve the productivity of those teams producing "less
> business value") Of course, since velocity is relevant only to a
> particular team, that's the wrong comparative measure---SO - any
> suggestions for obtaining such a quantitative measure? Yes, we
> can go to the PO and ask them to assess "business value" produced,
> but that seems to be an ephemeral. vague and Not quantitative measure.
were revenue dollars received cannot (I do not mean should not) be
used to assess the teams' comparative "productivity". It will not
work. It cannot work. I mean cannot in the sense that a rock cannot
hang in the air unsupported. I mean cannot in the sense that a cat
cannot build a bridge.
A car salesman sells 30 cars a month. A relator sells three houses
a month. Which is more productive, and what should the other one
do to become as productive as the one?
A knee surgeon replaces 75 knees a month. A brain surgeon removes
40 brains per month, or whatever they do. Which is more
productive, and what should the other one do to become as
productive as the one?
A cabbie delivers 2,000 passengers per month. A bicycle messenger
delivers 2,000 messages per month. Which is more productive, and
what should the other one do to become as productive as the one?
In times of stress, I like to turn to the wisdom of my Portuguese waitress,
who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
-- after Mark Vaughn, Autoweek.
- I have come across this scenario very often (almost 95% products/projects) in which defects escape and I have seen this irrespective of methodologies (or practices) used. Human can make mistakes (at every phase/activity) for various reasons however we would like to keep improving ourselves continuously. We measure 'defects escaped' and take it seriously, means, we get to the root cause and invest in required trainings/expectations.
We focus on design & code quality metrics, like, cyclomatic complexity, fan-in, fan-out, depth (inheritance) and run some code quality tools to check coding standard compliance and other parameters (like, memory leakage etc). We report this to management as well to keep them in loop. We measure test related metrics, like, # of test cases (manual vs automated), first time pass ratio, # of defects (open, fixed, closed, postponed) etc.
We do not focus much on velocity, thanks to this forum. We track release burn down, # of stories committed / # of stories achieved (to keep improving team's commitment level), # of demos accepted/ rejected by PO, # of times team got changes in middle of sprint (it is minimal but not zero yet, this helps in deciding sprint length, puts back-pressure on PO) and few more (customer satisfaction and employee satisfaction).
For us, agile is mix of Scrum and XP practices hence we focus on both.
Hariprakash Agrawal (Hari),
Managing Director | Agile Coach | http://opcord.com | http://www.linkedin.com/in/hariprakash
Software Testing (QTP, Selenium, JMeter, AutoIT, Sahi, NUnit, VB/Java Script, Manual) || Consulting / Trainings (Agile, CMMi, Six Sigma, Project Management, Software Testing)On Mon, Dec 13, 2010 at 9:11 PM, Ron Jeffries <ronjeffries@...> wrote:
Hello, woynam. On Monday, December 13, 2010, at 10:12:25 AM, you
wrote:It is possible, and not all that unlikely, to miss a test or write
> Sorry, but I don't see how "defects" can escape. If you're
> writing automated tests for every story, an "escaped" defect means
> that you ignored the failing test. Is that really that common?
one incorrectly. It would be possible, I suppose, to define Done as
"passes whatever tests we wrote" but that strikes me as a bit too
So an escaped defect would be something we didn't like, that we
agree we understood and somehow failed to get implemented and
tested.Sorry about your cow ... I didn't know she was sacred.