Abstract

Agile methodologies, like SCRUM, are popular process frameworks often applied to contemporary software development services. Mitrais as a software development services company has adopted SCRUM as a corporate standard in developing their internal software and in supporting clients. It has provided major benefits to our business by enabling faster delivery of software. But the delegation of control/practices inherent in Agile processes at individual team level sometimes creates some challenges for senior management.

What are the challenges?

With the introduction of Agile, some of the long-established software project governance methods have become weaker, especially the usage of non-standard sizing practices. As consequence of this, it is more difficult for senior management to objectively measure performance across projects, to perform effective monitoring and controlling in a consistent way, to provide reasonable estimation, and to make contractual commitments to potential clients during the presales process.

In a software development project, sizing is one of the crucial process because the size of the application is one of the main inputs for estimating efforts and other project planning activities. It needs to be performed objectively and consistently for successful project delivery.

There is, therefore, a need to find a new balance between the value of allowing an individual Agile team the freedom to deliver quickly, and the value of supporting them with more accurate sizing and estimation during the presales process. This is vital to securing client engagements and enabling objective monitoring and control across projects. In this article we offer a simple solution for Agile teams to perform effective sizing without the risk of losing the speed and flexibility benefits of Agile processes.

Software Sizing 

Story Points 

Story Points are commonly used in Agile projects, and is a unit of measure for expressing an estimate of the overall efforts that will be required to implement product backlog items or stories. It rates the relative effort of work using a scale in a Fibonacci-like format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. It may look counter-intuitive, but that abstraction is useful because it forces the development team to make serious decisions about the difficulty of a story.

Challenges of Story Points 

Since there is no objective definition of one Story Point, there is no clue to Agile practitioners or managers on how to measure consistently for different teams. Story Point counting results tend to be subjective and most likely based on the judgment of an individual team member. The productivity or velocity cannot be used to estimate other projects or even the next iteration in the same project when there are changes to the team structure. The results of Story Point calculations tend to be lower in terms of accuracy. Therefore, they need to be used carefully during the estimation, and variances between estimate and actual anticipated.

Functional Points 

The second sizing method is using Function Points. A Function Point measures the application by quantifying the functionality the software provides to the user based primarily on logical design [IFPUG Function Point Counting Practice Manual, Release 4.2]. As it is based on logical design, it is independently of the technology used for implementation and Function Point sizing can be performed at the beginning of software development cycle when software functional requirements are ready. To perform a Function Point calculation, we need to follow standard counting process and rules which make it possible to measure the software size consistently across projects.

Further information on the Function Point standard counting process can be found on the International Function Point User Group website at www.ipfug.org.

In general, Function Point counting calls for the identification of five key components as reflected in the picture above: Internal Logical File (ILF), External Interface File (EIF), External Inputs (EI), External Output (EO) and External Inquiry (EQ). Each component has a weighting factor based on its complexity. Here are the weighting factors of each component.

The sum of these weighted components will become Unadjusted Function Point (UFP). Function Point (FP) or Adjusted Function Point is the Unadjusted Function Point count multiplied by the Value Adjustment Factor based on the 14 General System Characteristics. The following is a diagram showing the Function Point counting procedure, adopted from the International Function Point User Group (IFPUG) Counting Practice Manual release 4.2. The diagram was developed using Business Process Model Notation (BPMN).

Criticism on the Function Point Analysis

The Function Point is a good tool to measure the software size. However, since its early stage, there have been several criticisms regarding the use of the function point analysis (FPA). We often hear such comments as follows:

• Function Point sizing is suitable for certain types of applications such as business application using database with a proper user interface. It is more difficult when measuring an application with intensive and complex backend process or rules.
• It requires time for practitioner or software developer to understand the terms and the standard counting process properly based on the Function Point Counting Practice Manual.
• Function Points cannot be directly used to estimate the effort related to non-functional requirements. It is only able to factor the functional size of these requirements using a Value Adjustment Factor (VAF).
• Due to the complexity of the counting process and rules the counting need to be performed by practitioner or specialist that has been trained on the standard counting process to determine accurate software size estimates.

Simplified Functional Points 

To face that challenges and have a standard size counting practice that suits an Agile environment, a simplified sizing guideline or formula has been introduced. It is derived from the Function Point Counting Practices Manual combined with some observations of our historical data. Here are two sample formulas that can be used to count the size depend on the input’s available during the counting process.

Case 1 – Size in unit point (SFP) = 16(X)+6.25(Y)

The above formula can be used when the following inputs available:

• Number of Screens – X
• Number of Tables – Y

The numbers or constant 16 and 6.25 have been derived through calibration process based on FP Complexity Tables, and the following assumptions:

• There will be about three EIs (to add, change, and delete) in every screen (Complexity – average, FP Factor – 4).
• There will be 1 low EQ in every screen (FP Factor – 4).
• 80% of tables are categorized as ILFs. The remaining 20% could be reference tables and/or code data.
• 1 Average Complexity Report (Average EO) will need a minimum of 4 tables.
• The number of External Interface Files is ignored unless otherwise stated.

Case 2: Size in unit point (SFP) = 16X+5.6Y + 5Z 

The above formula can be used when the following inputs available:

• Number of Screens – X
• Number of Tables – Y
• Number of Reports – Z

The constants 16, 5.6 and 5 have been derived through a calibration based on FP Complexity Tables and the following assumptions:

• There will be about three EIs (to add, change, and delete) in every screen (Complexity – average, FP Factor – 4).
• There will be 1 low EQ in every screen (FP Factor – 4).
• 80% of tables are categorized as ILFs. The remaining 20% could be reference tables and/or code data.
• 5 is the FP Factor for an Average EO, with 1 report equivalent to 1 average EO

To get the effort estimation for both cases above, we need to multiply by the implementation delivery rate or productivity number. Based on company historical data from our metrics baseline report program, the productivity factor of 1.69 hours per Simplified Function Point (SFP) can be used.

Effort (in person-hours) = 1.69 * Simplified Function Point (SFP).

This number was taken from the company’s historical data with some adjustments. For example, if there is a requirement to develop 1 screen maintaining 2 tables, then the size will be 28.5 SFP and the indicative effort to implement it be 48 person-hours or 6 person-days. Note that no statistical research has been conducted to calibrate the formula and the productivity numbers above. Small projects with low complexity or projects still early in their iterations could exhibit a higher variance.

When to measure and what counting method to use? 

Figure 6 shows a typically Agile Project Management process for handling a software development request from a Mitrais client, what method should be employed, and the recommended time to perform sizing. Sizing using a standard method can be performed by a specific team member such as a champion or by the software engineering process group who have been trained in the counting processes and rules.

Envisioning Phase 

During the Envisioning Phase, we usually have limited visibility of which engagement model that the prospect or client will engage. Considering the Cone of Uncertainty [2], it is important to use a standard sizing method (i.e. Function Point) and use historical performance data to estimate the effort, cost, schedule and any other contractual considerations.

Speculation Phase 

This is the phase where the engagement starts, and we usually received further details of the requirement specification. Here it is appropriate to use a standard sizing method (i.e. Function Point) to support the release planning.

Exploration and Adaption Phases 

During these phases, the team has a choice between using Simplified Function Points or Story Points.

Closure Phase

We suggest measuring the delivered “Done” product during the last iteration or sprint using Function Point to reflect the size of the application. By combining the total size (e.g. in Function Points) with the total effort spent for that project (e.g. in person-days), we will be able to get the “productivity” data that can be used to perform estimation in future projects. We recommend that this be done as part of the retrospective or project closure meeting process.

Conclusions

Objectively measuring performance and controlling the activities consistently across projects are standard practices in software development services. Agile software development projects should be no exception.

To manage it, an organisation needs an objective, standardised way of sizing its software output that is independent of the technology being used. Introducing a standard sizing method such as Function Point into Agile development team is a good idea, but must be handled carefully and within the recommended phases or periods as we have discussed. Training in standard software sizing practices and rules for all practitioners is also an option that may be worth to consider as a foundation. The objective is to get the benefits of using objective estimation and control methods without losing the speed and flexibility of Agile in software development.

Author:
Agus Winarta – Engagement Manager