So it's Estimation time again.  We've been using the Agile methodology for our project management for well over a year now, and while I think it's dramatically better than the waterfall model we had before, I can't help but think we've still to get it right in terms of estimation.

Our estimation technique involves the traditional agile approach of using Story Points, and comparing each Backlog Feature to eachother, and deciding on a relative size.  So, if I think that one story is worthy of size 10, but then I get a gut-feeling that another story will take twice as long to complete, then that story would be sized at 20.

Once you agree on how many Story Points you can achieve in a given cycle (Sprint, to use the terminology), you can select your immediate workload.

Fair enough, estimation is never going to be an exact science.  But I've got that feeling we can be a bit more accurate, or at the very least give reasons for our figures rather than just a shrug of the shoulders and a "sounds good to me" stare.

Function Point Analysis

I've given Function Point Analysis a whirl before.  And it's probably best filed under "Learning Experiences".  Not the best effort, but then I was fresh out of uni and the spec was incomplete, so that's understandable.  Also, I think we were trying to fly before we could crawl.... which is where maybe merging this approach with that of Agile's flexibility might, I repeat, might work.

Another slight criticism of Agile I have is that it's really really really hard to try and estimate how big a task is when all you've got to go on is a sentence from a product backlog.  No spec, no prototype, no nothing.  Okay, so you've got a bit of domain understanding and there's always people you can speak to beforehand to give you a picture as to what's involved, but until you've actually built a picture in your head in terms of Objects, I/O, UI etc.... it's all a bit 'up in the air'.  Admittedly, as is my current understanding, this is okay, and your estimations will get better as the project begins to take shape... but if we performed FPA on each feature then you would need to know, in advance, the following:

• Internal Logical Files
• External Files
• External Inputs
• External Outputs
• Queries

As well as the Value Adjustment Factor based on general system characteristics of the project, this would give some quantitative measurement of what is to be delivered.  And it has proof!  You can go back to someone's estimates and actually find out why Feature A came out as twice as complex as Feature B. 

Agile Function Points

So, this output then is just treated as Story Points are by Agile, in that x number of story points can be delivered in a week, and velocity can be used to guage future performance.

What the engineers are saying is, "look, we don't need a full functional spec and UI screenshots describing exactly how everything will work, but all we need to know is 1) What's coming in, 2) What's going out and 3) How much user interaction is there going to be?".  And the goal donors can say "Okay, so we've not told you exactly how we want it done, but we've given you enough information to go on that you can't come back to us in a month and say that the database schema has doubled in size".

And that seems like a decent compromise to me.