Why have an estimation technique?

After four years in a large consultancy, it’s pretty obvious to me that you should generate proper estimates before you start on a piece of work. But, granted, that’s not obvious to all. Before I learnt how to do it, I too thought of “estimation” as some arcane art that you learnt over the years and that you couldn’t really explain to anyone. Not so. Say hello to the world of measurable, repeatable, somewhat accurate, and, most importantly, explainable estimation.

FPA is first of all repeatable. Once you’ve decided on how you measure function points, you can apply it over and over again, and constantly tweak your “coefficients”, to get better and better at doing estimates. This is because FPA estimates are easy to track against actual work, and adjust as you get more and more “data points”.

FPA is also fairly accurate. The main reason for this, in my opinion, is that FPA requires you to break down your work into small chunks and think about what goes into each chunk. That may still be wildly inaccurate - you may well have forgotten a huge component somewhere in there - but ultimately it’s way more accurate than a gut-level estimate. Funnily enough, I’ve found my gut-level estimates and my FPA estimate tend to agree, without me tweaking any numbers, even though they approach estimation from completely different angles (FPA = bottom-up, gut = top-down). Go figure.

Finally, FPA is explainable. It can be explained in excruciating detail to your clients, your manager, your employees, etc. It can be taught. It can be “institutionalised”. It’s a great people tool. With FPA, you don’t ever have to sit in a meeting, be told “well, I don’t think it should take this long”, and be unable to reply back with something really convincing.

What is FPA, then?

Function Point Analysis, despite the grand title, is a really simple technique. The core concept is easily represented in 4 simple steps:

1. Break down the piece of work in as many small chunks as you can (by screen, or by screen element.. whatever suits you - these are the rows of your estimates table
2. Pick some function points that make sense for your domain (more on this later) - these are the columns of your estimates table
3. Assign points from 0 to about 5 at most for each functional chunk - these are the values at the intersections between rows and columns
4. Add up the points for each functional part, maybe throwing in some sort of adjustment coefficient

What you get out of this is a very decent relative weighting of your various tasks. You can then pick a few really easy ones and use those to “calibrate” your coefficients, and thus automatically get more or less valid estimates for everything else.

Let’s go through a concrete, but very simple, example. I was asked to build a facebook application recently. Here are some of the chunks I broke it down into:

So far, nothing extraordinary. The next step is to pick some function points. You’ll probably only do this once for each “type” of project. For instance, facebook apps are all going to have more or less the same function points. In fact, most web apps will have more or less the same function points. My choice in this case is:

• Inputs - the number of ways the user can do stuff on the page/element
• Outputs - the number of dynamic things the page/element displays
• Exception conditions - the number of ways that the inputs can be rejected by the business logic
• UI Factors / AJAX - a general weighting factor to cater for the UI complexity and dynamic elements
• External integration factor - the number of external (ie not yours) systems the element has to integrate with

Another one I’ve found of some use is an “infrastructure” factor. That’s a general weighting factor to cater for the fact that some elements will require new infrastructure to be built and others won’t.

In assigning those points, you can use your gut to help you decide how many points to allocate. In my experience, you’re more likely to err on the side of putting too few points than too many, so it’s probably better if you err on the side of too many at first. You can quite easily go through and re-evaluate some outrageously large bits if you feel that they’re wrong. In all cases, ensure you are able to explain why you allocated a certain number of points to a certain element.

So, let’s chuck those in and assign some points:

The final step, adding those points up with some sort of coefficient, is the hardest on your first estimate, because you’ll really just have to wildly guess at the coefficients. But the beauty of having these estimates written down is you’ll be able to measure them up against actual work, and then you’ll have the full power of Excel’s Goal Seek functionality to allow you to fine-tune them to minimise the discrepancy. Here is my stab at it for this particular project:

As I hope you can see, this is actually a really straightforward technique to use. As soon as you start using it, you’ll gain much more confidence in your own estimates (if you were previously basically just guessing), and your estimates will start getting significantly better as you go through more and more projects and gather better data to help pin down those coefficients.

Final notes

Now, I can hear the hardcore technical project managers in the back start to boo me because I’m not following the letter of what FPA is supposed to be about. One of the key points hammered in in most of those over-complicated articles about FPA is that you should measure the function points very accurately, and always use the exact same function points for all the projects, etc. FPA is such a neat concept that all sorts of very smart people have gone and abstracted it in all sorts of ways to make it correct for “all projects”, but somehow the result of that abstraction, in my experience, has been that FPA has become hard to use, complicated, and has pushed accurate estimates back into the realms of arcane stuff that only a few people know about.

It doesn’t have to be so. As I hope I’ve shown in this article, FPA can be really simple so long as you use it as what it is meant to be - a much more accurate guess - rather than what it’s not - a foolproof technique to arrive at rock-solid estimates (my opinion about that: it doesn’t exist).

Feel free to post below and let me know what other estimation techniques you may have used, or even if you used FPA and found it useful. I’d love to hear about it.