Link Details

"Running Tested Features" sound suspiciously like the function points of old, which are quite rightly scorned in the article. How can you compare the number of RTFs produced this month compared to last month when no two RTFs will ever require the exact same amount of effort?

1. Estimate the size of each story (in points, ideal days, etc.). For example, "Add a shopping cart to the website" might be 5 days of estimated effort, and a set of 3 other stories might total another 15 days.
2. At the end of the iteration (say 2 weeks or so), see what actually was completed, and give yourself credit for only "done" stories. In the example above, let's say you only finished the shopping cart story, for a total of 5 days of credit.
3. For the next iteration, start with the assumption that you can only do 5 days of estimated work. Obviously if you finish early you can add on another story, but this is just a baseline to communicate with the customer.
4. To see how things compare between iterations, just use the completed effort value to establish a trend. Very short term trends probably aren't interesting, but over a few iterations, you'll be able to see if the amount of work completed is constant, increasing, or decreasing.

That's the process in a nutshell, although I've probably oversimplified the details of estimating.

We've been working on a formula, combining SLOC and Feature Points. Basically during design we estimate Feature Points, Complexity, and target LOC, and Lines of Comments for all major elements and most minor elements of each module, and then we apply a basic "Overhead" bonus to each value to cover "Glue". Overhead we come up with with an existing formula, basically a value based on Language, Team, Experience, etc, kind of ripping chunks out of Cocomo II.

But basically Calculate Feature points, lets say 100 for simplicity.
Next Complexity on a scale of 1-100, typically this falls around the mid 20's to mid 40's, 1 would be "Hello World" in Basic, 100 would be writing the Linux kernel from scratch with no prior example code to work from.
These two give us our target LOC, which is really what the formula does, lets say FP * Complexity, just for simplicity since I don't know the current version of the formula off the top of my head.
Now Lines of Comments are easy, we stick with 25% of the LOC total, so if you have 100 LOC, you'd have 125 Lines of Code + Comments.
Multiply by Overhead.

The full version gives us good estimations on final SLOC, and how efficient each developer is. The final result of the entire process was originally to give us our Cocomo II inputs, so the entire thing is very "prior project" heavy.