Measuring Productivity #3: Possible Measurements

 

The zeroth measure of productivity is showing up. Sorry I haven’t been showing up, but I have to admit, sleeping is good 🙂 Ok, back to business.

When I tried to calculate productivity of a team, here’s what I measured for one team over the course of five releases (Apologies to bloglet subscribers; tables don’t email well):

Release Number of people Number of features
(the same people calculated the number of features each release)
Number of calendar months Lines of code produced
(total product size)
Defects pre-release Defects post release
Release 1 4 40 6 35,000 uncounted 80
Release 2 8 40 12 38,000 120 over 100
Release 3 12 45 18 46,000 200 150
Release 4 12 50 12
(product not released)
50,000 >300 (product not released)
Release 5 8 50 8 38,000 150 20

Ok, so this team had a number of problems. The first problem was that they didn’t think defects was part of what they produced, so they didn’t count defects for the first two releases. By the time they started counting defects, the defects overwhelmed them.

Their management didn’t think counting defects was important at first, which is why their apparent productivity was so high for the first release, and not too bad for the second release. By the time they attempted release 4, the product was so error-ridden, they couldn’t make any progress on features, and were adding to the bloat and defect levels. For release 5, they instituted peer reviews and better end-to-end testing, so they could see if their fixes worked.

Contrast this traditional development with more agile projects. In an agile project, you can determine each iteration’s velocity (number of user stories per iteration) and the number of outstanding defects. Because people on agile projects tend to perform test-first development the sheer number of defects tends to be fewer. And, if the testers and the customers write user acceptance tests in advance of the first line of code, agile projects tend to have fewer egregious defects. (The one problem I don’t know how to solve with agile projects is keeping the customer involved.)

So if you’re measuring productivity, try measuring size, time, number of people, and defects. Once you’ve calculated some sort of team productivity, see if you can figure out personal productivity. Just don’t forget that a person’s productivity is based on their entire contribution to the product, not just the number of lines of code (or tests or whatever) they contribute.

2 Replies to “Measuring Productivity #3: Possible Measurements”

Leave a Reply