4655RE: [scrumdevelopment] SCRUM performance measurements
- Sep 29 10:13 AMHi 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:
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:
# 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
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,
Author of User Stories Applied for Agile Software Development
From: Patrick Steyaert [mailto:steyaert.patrick@...]
Sent: Sunday, September 26, 2004 12:25 PM
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.
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to:
Yahoo! Groups Links
- << Previous post in topic Next post in topic >>