Function Points are NOT an Estimating Model

It continually amazes me that there is such confusion in the marketplace and in industry about function points (FPA) and their role in estimating the cost or effort associated with a software development project. First and foremost, Function Points are NOT an estimation model.

(Note: for a basic primer on IFPUG Function Points, send me an email and I’d be happy to send you a copy of my article “Requirements are the Size of the Problem”.)

Function points (unadjusted and the “functional size”) strictly represent the size of a piece of software based on its functional requirements. The allocation of “points” to the functions performed by the software is based on assigning a standard ordinal number to a “function” that the software must perform (a unit of work). Currently, the most popular methods of function point sizing based on the International Software Benchmarking Standards Group (ISBSG) productivity database are the International Function Point Users Group (IFPUG) method, and the Finnish Software Measurement Association (FiSMA) function point method.

The function point (or functional) size is similar to the square foot size of a building’s floor plan (or square m) – it is one measure of size – and it works well as part of determining many things.
BUT size is not the same thing as estimation OR AN ESTIMATING TECHNIQUE!

Function point size can be used (along with MANY other factors) to determine work effort to develop (build) the software. Productivity factors or delivery rates (FP/hour) are derived by taking the FP size of a piece of software, together with the work effort hours it took for a team to build it (based specifically on the TYPE of software, the requirements for QUALITY (reliability, accuracy, functionality, usability, etc), the skills, and WHAT TASKS WERE INCLUDED!

Here’s the crux: FUNCTION POINTS DO NOT EQUAL WORK EFFORT HOURS OR COST. While size is a major driver (in the same way that a larger house takes more time to build), the relationship between FP and effort or cost is NON-LINEAR! There are many more factors that just raw size involved in determining the cost and effort to build software.

It may be helpful to consider an analogy (again one based on construction – which is not a perfect analogy but one that serves to illustrate). If I need a 1000 square foot building – can you tell me how long it will take to build? And what can I anticipate will be the cost of that building? The answer is that it depends on MANY factors (such as location, pre-existing structures, type of building: anufactured, or custom or prefabricated or whatever), and many other things. Builders might provide me with an average delivery rate based on STANDARD characteristics (like a standard home with 2 bedrooms and a living room, kitchen and bathroom in the US midwest), and an average effort based on what similar buildings have taken to build IN THE PAST HISTORY. However, there is not ONE rate for all structures – it varies based on location, type of construction, building codes, labor costs, etc.)

The same is true when we consider function point size and the effort and cost it will take to build a piece of software. Consider the aforementioned example applied to software development: How much cost and how much effort will it take to build software that is 1000 FP? The appropriate answer is that it depends on the characteristics of the software, labor costs, methods of construction, AND its functional size. The software measurement and development industry has developed rates of FP / hour and cost per FP for projects with “standard” and similar characteristics (recall the “average” price per square foot or average rate to build?) Note that any “average” rate is BASED ON PAST PROJECTS (that took “x” amount of hours to build a particular size, type, and similarly constrained by quality, system – but there is not a one size fits all rate!

New Book available to explain these and other concepts about Function Point sizing: I am proud of the new book I co-authored with Manfred Bundschuh (formerly the measurement coordinator for AXA Insurance in Germany). It was published in Sept 2008: The IT Measurement Compendium – Estimating and Benchmarking Success with Functional Size Measurement (the Amazon link is featured together with reviews by Capers Jones, and also by Peter Hill (Executive Officer for ISBSG at

The book outlines and explains in clear English these concepts and presents all five of the ISO/IEC conformant Functional Size Measurement Methods including the aforementioned two: IFPUG and FiSMA, as well as NESMA from the Netherlands, Mark II from Britain, and COSMIC by the COSMIC consortium.

Have a great week, and please let me know what you think of this and other postings here.

p.s., To all of you who attended my webinar on December 3, 2008 “The Certified Scope Manager (CSM) – A New IT Job Role) sponsored by CAI – thank you! If you missed it, send me an email and I’ll put you in touch with the site that has options to listen to the recording.

Best regards,

Carol Dekkers email:

Contact Carol for your keynote and speaking needs – she translates technical subjects into easily digestible soundbites – in a humorous and forthright manner. See for details of topics and opportunities.

View also Carol Dekkers’ general blog at

============Copyright 2008, Carol Dekkers ALL RIGHTS RESERVED =============

Close Comments

Comments (3)

  1. Hi Carol … I know the square foot / meter analogy has been out there for a long time but I find it comes up short in properly sizing because the square foot is like a building with rooms that you can navigate around in but it has no function.

    Similarily, an application can have a framework mocked up that can be navigated but it has no function.

    The true functionality comes from the features that are put in the framework.

    For example; a building can have different kinds of doors; wood, steel, screen, cloth. Each kind of door has a reason and a specific function. Additionally, security can be added to the door with a lock. A bathroom can have a sink but it is not functional until plumbing is added to bring in cold and hot water as well as a plug to hold the water in the sink. And, don’t forget about the drain unless you want to be able to recycle the water and use it to wash the floor!

    Applications work the same way in that they require functioning features that actually do something other than take you from screen to screen.

    Anyway, I know you understand all this and my point is that all these features is where the value comes from and not the framework that establishes the boundary within which the function resides which is what I equate the square foot analogy to.

    Bill Ravensberg

    p.s. Hope you are enjoying the warmth of Florida over the cold of Canada, eh! Oh, that reminds me that you can also add insulation, heating, and cooling to the building. 😉

  2. Thanks Bill. It is always a good reminder that when we peel the onion apart and examine the “functionality” of a software intensive application or system, we find that the basic square foot size is only a part of the overall size.

    However, when readers have no idea that software can even be sized at all, the square foot analogy is a good simplistic introduction to the world of software measurement and functional sizing. While not a perfect analogy, it does work to align people to the functional sizing concepts so that they can progress to the state of being able to digest more complex ideas such as those you purport here.

    Stay warm in the GWN (Great White North) of Canada’s Ontario Great Lakes region – and look forward to a mere 10-20 weeks before golf season starts again.


  3. Indeed, how could this ever been mistaken? When you start thinking about some piece of software, it will be a few functions. Then you start analyzing the problem. Oh wonder! – the initial FP size starts increasing quite a bit… Then you establish cost constraints and start solution design. This causes size to decrease somewhat, but usually not much. However, a good solution design is capable to significantly cut overall cost!

    That was the story in our last big project. The customer invested quite a bit of money into analysis but provided only an incomplete concept. He didn’t understand the problem he was facing.

    We did an initial FP count in order to understand the problem. This enabled us to tell the customer early enough that his scope understanding was incomplete. On the other hand, the FP count proofed to be an excellent foundation for the solution design. This design work enabled us to provide accurate cost estimation for the full solution.

    The ISBSG data base was of great use for this, not as an estimation model, but to find out what functional size similar projects had at the end. It did help to explain why the initial estimates were unrealistic.

    The customer could adjust budget and schedule in time; the project became a success. Otherwise, it could have become a failure simply because adjusting a budget is difficult for many large organizations (and small ones, too!). This is SCOPE MANAGEMENT, not cost estimation.

    The initial project plan worked as expected, and the cost remained within the revised budget. The FP Count was instrumental for this success, but NOT as an estimation model!

    Carol, this is a real good point!

Leave a Reply

Your email address will not be published. Required fields are marked *