Function Point Analysis Example: Hands on with Agile Development

In an earlier article, I explored some history and definitions of agile and other software development methodologies. I also discussed how Function Point Analysis (FPA) can be used in the measurement of agile projects and how the definition of the project is critical to this process.

In this article, I will demonstrate the use of FPA in agile development through a hands-on example.

Our Project
Consider the following software development project: A basic human resource system is being developed from scratch. This means that all of the functions are new to the application, which itself is new. We can use FPA to measure the size of the project. Because there are no one-time conversion functions and the fact that we are defining a new development project as containing all of the functionality required for the application, the FPA size in unadjusted function points will be same for the entire application as it is for the project.

The application requirements define addition of the following functions:

1. A human resource logical file
2. Maintenance transactions to add, change, and delete data in the human resource logical file.
3. A human resource report

The technology being employed by developers in order to meet the requirements makes no difference to the FPA sizing. For example, the human resource file may be a flat file, a physical table or group of tables. The maintenance functions may be online or batch. Operating environments and platforms have no meaning here. For the unadjusted sizing, FPA is only concerned with the required functions themselves from a logical user point of view.

The International Function Point Users Group (IFPUG) defines an adjustment that may be made for environmental factors, called the Value Adjustment Factor (VAF). Such an adjustment is not employed by all FPA users, partly because it does not comply with ISO/IEC 14143-1:2007 as do the other standards. It will not be applied for this example.

Let’s view the example in a couple of ways in order to show how FPA is versatile enough to be used in different situations.

FPA Nuts and Bolts
The functions noted above will be counted according to IFPUG’s Counting Practices Manual (CPM), which defines five function types:

• Internal Logical File (ILF): User-identifiable group of related data maintained within the application.
• External Interface File (EIF): User-identifiable group of related data referenced by the application but maintained within another application.
• External Input (EI): Unique elementary process that processes data coming from outside the application boundary.
• External Output (EO): Unique elementary process that sends data outside the application boundary. Calculations, derivation of data, or maintenance also takes place.
• External Inquiry (EQ): Unique elementary process that sends data outside the application boundary. Calculations, derivation of data, or maintenance do not take place.

The CPM also specifies how to apply a complexity factor for each function defined above. This is based on the number of data element types (unique logical fields) and record element types (logical sub-groupings) for the data functions, the ILFs and EIFs. For the transactional functions—EIs, Eos, and EQs—the complexity factor is based on the number of data element types that cross the application boundary as well as the number of file types (ILFs and EIFs ) referenced or maintained.

By measuring each function as above, we arrive at a complexity weight of low, average, or high. The CPM provides tables where the weight factor for each function type is given an unadjusted functional size. For example, a high complexity ILF has a functional size of fifteen unadjusted function points, whereas an average ILF has ten. An average EQ is four unadjusted function points and a low EQ is three.

For the sake of simplicity, let’s assume that all functions measured in our example, except the delete, are of average complexity. Delete functions are commonly counted as being low complexity since in many cases only the key value, a possible message and the user action are required.

Development or Enhancement Project Example Regardless of Methodology
Let’s measure the functional size of the project regardless of what methodology was used for development. By doing so, we will determine the objective size of the project in FPA terms.

Table 1. The Functions Developed for the HR Project Along With Their FPA Sizing Parameters.

For the project defined as it was above, the functional size is twenty-five unadjusted function points.

Agile Methodology Count—Example One
If the project used agile development and was split into two sprints, here is how we may view it through the counting of individual sprints:

Table 2.  Sprint One Function Point Count: Data and Maintenance Functions Added

Table 3. Sprint Two: Report Function is Added

In this example, when function point counts for sprint one and sprint two are added together, they will equal the total project’s (and application’s) function points, which in this case is twenty-five.

Agile Methodology Count—Example Two
Agile methodology introduces additional opportunities for information gathering, such as the sizing of sprints.  Let’s say that the first sprint is the same as for example one, but an additional data element is added to the logical file and the maintenance functions in the second sprint. In this case, the FP count after the first sprint would be the same as sprint one above, but the second sprint of all of the functions—the file, maintenance, and the report—would be counted as being changed. 

Table 4. Sprint One Function Point Count: Data and Maintenance Functions Added

 Table 5. Sprint Two: Data and Maintenance Functions Changed and Report Function is Added

In the second example, the overall project version is not the same as the sum of the agile sprint counts, because some of the functions are counted twice as part of sizing the sprint.

When the function point counts for the two sprints in the second example are added together, the sum is greater than the total amount delivered for the project (forty-six), which is incorrect. To obtain the function point size of the project, it is always necessary to analyze what is ultimately delivered to the end user at the conclusion of the effort.

Whether to count by sprint or by project depends on the goals of the metrics program. Counting for each sprint provides additional measurement capability since it is now possible to determine the cost of changing functionality delivered in an earlier sprint; this is the difference between the sum of the sprints and the single version of software delivered. Even though the individual sprints cannot be added together to derive the final project count, a final count can be performed for the entire project at the time of delivery. This is similar to the counting that would be done for a traditional waterfall project.  In this instance, the sprint counts provide the input for establishing the final project count. It is also possible to use the sprint FP counts to arrive at a count of the delivered functionality by ensuring that no function is counted more than once for the delivered function point count.