Function Points and Agile Methods (I promise I won’t tell)
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.
The biggest problem is the politics associated with early estimates, but that’s not the fault of FP-based estimates themselves. Besides, if there’s even one old-school executive among the stakeholders (and they haven’t all died, trust me), I’d much rather have a metrics-based estimate to stand on than, “Well, the team met, and this is how long they think it will take,” even though the latter is probably just as accurate.
My reliance on Function Points is grounded in experience. I used Source Lines of Code (SLOC), various home-brew counts of project parameters, and Use Case Points before settling on Function Points. To paraphrase Churchill, “Function Points are the worst size measurement there is, except for all the others.” But if you have some other metrics for estimation, use them, provided they can be applied quickly. If you need to request budget to prepare the initial estimate, that’s too slow.
The second biggest problem is hanging onto the FP-based estimate once you’ve decided to start. Put the FP count in the bottom drawer and forget about it. Put story points on all the user stories, zap everyone who saw the FP-based estimate with your Men In Black Flashy Thing, and get on with it. After two or three iterations, you’ll have measurements of actual progress, and that’s the most accurate type of estimate there is.
Then, when the project’s done (or at each release point), do an as-built FP count and drop it in your project “database” (mine is a mere Excel spreadsheet) along with the total effort and some notes about the project, team, technology, etc., for use next time.
Is it worth getting a person or two trained in Function Point Analysis if you’re an Agile shop? Based on my experience, I’d at least consider it. Just don’t tell the people who trained you on agile methods.