Are function points relevant in 2014? In this case, the question is whether function points are relevant to the size of an application, a development or an enhancement project. IFPUG Function Points were proposed in 1979 by Allan J. Albrecht, published in 1983 by Albrecht and Gaffney while at IBM and then updated and extended over the years. Just like using a tape measure to determine the size of the room, function points are a tool to determine the size of the application or project. In order to determine relevance we need to answer two questions:

  1. Do we still need to know “size”?
  2. Is knowing size sufficient to tell us what we need to know?

Size as a measure has many uses, but the two most often cited are as a component in parametric estimation and as a denominator in metrics such as time-to-market and productivity. While there still might be an intellectual debate on the effectiveness of estimation, there has been no reduction in the sponsors, executives, purchasing agents and the like requesting a price or an end date that you will be held accountable to meet.  Until those questions cease, estimation will be required. Parametric estimation processes (the second most popular form of estimation after making up a number) require an estimate of size as one of the inputs.  Parametric estimation helps to avoid a number of the most common cognitive biases exhibited by IT estimators: optimism and assumption of knowledge.

Size is also used as a normalizing factor (a denominator) to compare effort (productivity), duration (time-to-market) and defects (quality). This type of quantitative analysis is used to answer questions like:

  • Is our performance improving?
  • Are the techniques being used delivering value faster?
  • Are we staffed appropriately?

Function points deliver a consistent measure of functional size based on a consistent set of rules.

The second and perhaps more critical question is whether the balance between functional requirements (things users do) and non-functional requirements (things like usability and maintainability) have changed when implemented in the current environment. If the balance has changed then perhaps measuring functional size is not relevant or not sufficient for estimation or productivity analysis.  A literature search provides no quantitative studies on whether the relationship between functional and non-functional requirements (NFRs) has changed.  Anecdotally, the new architectures, such as heavily distributed systems and software as a service, have caused an increase in the number and complexity of NFRs. However there is no credible academic evidence that a change has occurred.

It should be noted that some measurement organizations, like IFPUG, have developed and begun evolving measures of non-functional size.  IFPUG has released the SNAP version 2.1, which measures the size of NFRs. These measures are still in the process of being incorporated into software estimation tools and are considered an augmentation to functional size measures like IFPUG Function Points or COSMIC (another form of function points).

Function points are still relevant because organizations, sponsors and purchasing agent still want to know how much a project will cost and what they will get for their money.  Organizations still want to benchmark their performance internally and externally.  Answering these kinds of questions require a standard measure of size. Until those questions stop being important, function points will be relevant.

FYI: Many times the question of relevance is really code for: “Do I have to spend my time counting function points?”  We will tackle that issue at a later date, however until then if effort is the real issue, call me and let’s discuss Quick and Early Function Points.