lines of code

[James Kanze]

I tend to track productivity the XP way, by tracking the
number of story points completed in an iteration. This gives
a good indication of a team's performance, so it probably
indirectly tracks code complexity as well.

I assume that "story points" is just a new name for the
"function points" that Jerry mentionned. So how do you know
that all of the "story points" are of similar complexity. The
usual way is to consider the number of lines of code per "story
point"---if one particular story point requires a lot more lines
than the average, you should want to know why. Perhaps the
implementation team wasn't up to speed, or lacked some vital
information. Or perhaps you defined your story points too
widely. In any case, you would want to do something about it.

FWIW: lines of code per function point is a very good example of
where lines of code is used. If there's too much variation, it
could be an indication of a problem which needs addressing.
Another usual measure is number of errors over lines of code;
too many (say, more than about 1 error per 100,000 lines of
code), and you know that your process needs improving.
(Curiously enough, reducing the number of errors per line of
code almost always ends up reducing the number of lines of code
as well.)

 

[Ian Collins]

I assume that "story points" is just a new name for the
"function points" that Jerry mentionned. So how do you know
that all of the "story points" are of similar complexity. The
usual way is to consider the number of lines of code per "story
point"---if one particular story point requires a lot more lines
than the average, you should want to know why. Perhaps the
implementation team wasn't up to speed, or lacked some vital
information. Or perhaps you defined your story points too
widely. In any case, you would want to do something about it.

Almost, it's more down to experience, the team knows roughly now many
points a story is worth. If the estimate is more than three, the story
is too complex is has to be broken down. We never really consider lines
of code, more how long it will take to design, test and code.

Another factor that makes lines of code not particularly useful to us is
there tend to be more lines of code in the unit tests than in the
deliverable code.