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

4657RE: [scrumdevelopment] Re: SCRUM performance measurements

Expand Messages
  • Mike Cohn
    Sep 29, 2004
    • 0 Attachment
      Also, the developers don't know I captured those metrics. This was purely a
      research effort to measure the impact of Scrum on a team. I pointed out the
      most significant metric--that the CEO is ecstatic by what he sees day-by-day
      and sprint-by-sprint.

      --Mike Cohn
      Author of User Stories Applied for Agile Software Development
      www.mountaingoatsoftware.com
      www.userstories.com

      -----Original Message-----
      From: Victor Szalvay [mailto:victor@...]
      Sent: Wednesday, September 29, 2004 5:43 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: SCRUM performance measurements


      I figure this is obvious to agilists but I have been fielding a lot
      questions lately on dubious metrics. Metrics are a tricky thing that
      must be selected very thoughtfully. For example, it strikes me that
      lines of code (LOC) as a metric is dubious because it encourages
      developers to increase volume of code produced. In most OO
      environments an overarching quality goal is to increase code re-use
      and decrease repetition. LOC on the other hand encourages developers
      to cut-n-paste their way to more lines of code, decreasing overall
      maintainability and quality. If you take a messy OO project and
      reduce the total lines of code by refactoring, I would call that
      progress...

      It's the same story as other "metrics", some developers will find a
      way to make themselves look good in light of the metric. Some folks
      want to compare estimated to actuals still. The developers will find
      a way to make them match up, at the expense of something else (most
      often quality).

      This is why defining good metrics is so tricky.

      (clarifier: I know Mike doesn't advocate these metrics, just a
      commentary after reading his post.)

      -- Victor Szalvay

      --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
      wrote:
      > Hi Patrick--
      > Sorry for taking a few days to reply but I was working on exactly
      this
      > question for a team this week and wanted to have solid answers.
      >
      > This team used a waterfall process from 2001-2003. I switched them
      to Scrum
      > at the start of this year. They write in Java. Here are some
      measurements:
      >
      > 2001-03 2004
      > Lines of code per programmer-month 389 1206
      > Defects per thousand lines 10 2.9
      >
      > Some code metrics as measured in Feb 2004 (2 months after Scrumming
      started)
      > and today. These show improvements in the code being written:
      >
      > 2/04 9/04
      > # of packages 43 118
      > # of classes 718 1,128
      > # of methods 10,451 14,424
      > lines of code 119,950 145,897
      > lines per class 159 121
      > Methods per class 14.6 12.8
      > Lines per class 10 8.4
      > Cyclomatic complexity 2.3 2.1
      >
      > Keep in mind that things like "methods per class" going down so much
      means
      > the new code written using Scrum went down even further because the
      overall
      > average is shown above, not just totals for the new code in the
      right
      > column.
      >
      > Note that throughout, lines of code is "non-comment source
      statements". A
      > caveat: I didn't count the JSP lines in the 2001-2003 version (not
      many of
      > them as much had been migrated back into servlets) or the velocity
      templates
      > in the 2004 system. If those were measured, things would look even
      better
      > for the latter metrics.
      >
      > I think these show a very compelling advantage to Scrum. This team
      became
      > more than 300% as productive (as measured my lines, which is
      somewhat
      > questionable as a measure) and has 80% fewer defects. More
      importantly, the
      > CEO is ecstatic about what the team has achieved. They're 3x faster
      in lines
      > but are probably 10x in delivering business value. For example, the
      team's
      > best programmer spent all of 2003 on a feature that has still not
      been used
      > ONCE. That doesn't happen with Scrum.
      >
      > Let me know if you have any questions,
      >
      > --Mike Cohn
      > Author of User Stories Applied for Agile Software Development
      > www.mountaingoatsoftware.com
      > www.userstories.com
      >
      > -----Original Message-----
      > From: Patrick Steyaert [mailto:steyaert.patrick@p...]
      > Sent: Sunday, September 26, 2004 12:25 PM
      > To: scrumdevelopment@yahoogroups.com
      > Subject: [scrumdevelopment] SCRUM performance measurements
      >
      >
      > *.*;
      >
      > While introducing SCRUM to software organisations, the question pops
      up of
      > what *bottom-line* improvements can be expected - decreasing number
      of bugs,
      > lower cost of quality, faster time to deliver, ...
      > My question is whether there are people out there, that have
      actually
      > measured such improvements, and whether such measurements have been
      > collected ? Are there experiences in using such measurements to
      actually
      > track progress of introducing SCRUM into an organisation ?
      > All input welcome.
      >
      > Patrick.
      >
      >
      >
      >
      > To Post a message, send it to: scrumdevelopment@e...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@e...
      > Yahoo! Groups Links




      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:
      scrumdevelopment-unsubscribe@...
      Yahoo! Groups Links
    • Show all 19 messages in this topic