Posted by Robert Merrill on July 13, 2009 under Agile BA, Agile Methods, Estimation | 
If you’re an IT shop considering agile methods, your existing Function Point Analysis (FPA) capability can be a a valuable asset. It freaks many agile-methods advocates out when I tell them, but I routinely follow a user story workshop with a Function Point count.
I already knew FPA when the project-contracting house I worked for went agile. I found I could count the Function Points from a couple of dozen user stories in a half day or less. (Often I discovered some missed stories in the process.) With some project history on hours per FP for the teams I supported, and some multiplication, I had a quick, factor-of-two effort estimate. Flip the factor-of-two uncertainty off of the effort and onto the scope (you know those stories are going to change, anyway), and there’s the core of an agile project proposal. We had about a 1-in-3 close rate, and less than 10% of our projects failed.
Now that I’m consulting for software-intensive businesses and their software teams, the same estimate can be used to request a team and a budget through your established governance process. Read more of this article »
Posted by Robert Merrill on September 30, 2008 under Project Set-Up |
I keep getting a trickle of traffic from this post I made on an InfoQ forum back in July, so I really ought to write more on the topic (I finally did). But for now, here’s the comment that continues to spark interest.
Maybe outsiders see the lack of OUTWARD-FACING metrics, that can be compared across projects or even industry-wide. Agile thought leaders seem metrics-averse, maybe out of reaction to the way metrics have been used (and abused) in the past. As I see it, the basic four, productivity (X/effort), velocity (X/time), quality (defect/X), and value (benefit/X) still apply, and within a project, agile teams track and respond to them, in their own effective ways (measured velocity, continuous integration and automated tests, planning game). But when you need to compare projects, you need a more portable X, or what I call “an ounce of software.”
I used to do project set-up for a contracting shop that used agile methods. We needed a decent estimate before we even got the chance to establish a velocity. That estimate needed to be clearly traceable to the initial requirements, to help the client think “scope-to-budget” from the start. The estimate also needed to be tied to actual results on other projects, so it couldn’t be pressured down. Based on these requirements, I introduced Function Points. Usually dismissed with a sniff by agilists, they did just what we needed, and didn’t interfere with people and interactions at all. They also helped our initial story development by revealing gaps and implied stories
You can read the complete thread, “Agile Measurement – A Missing Practice” on InfoQ.
