Function Point Analysis and Agile Methodology

Software development and maintenance can be a challenging endeavor. Whether and how you measure productivity and quality, as well as how you go about doing project estimation, are among the major concerns. Function Point Analysis (FPA), in combination with other metrics, provides reliable and accurate measures that may be invaluable to the organization. Together, these methods can reduce risk and ensure project success by providing an accurate account of the effort required to complete the project. Function points measure the amount of business functionality an information system provides to a user. Such measurement may take place before (as an estimate), during, or after the project development, as required.

Although FPA is recognized by the International Organization for Standardization (ISO) as an industry-standard measurement method, the use of new software tools, methods, and technologies raises questions about whether FPA is applicable as a measurement method. Many organizations use function points as part of their waterfall software or systems lifecycle, and FPA can work just as well with agile. This article, the first of a three-part series on how to use FPA to improve your software development process, will demonstrate that FPA is a valid measurement of agile software development.

History and Definitions
Software metrics and particularly FPA are closely linked with project management; measurement takes place before, during, and after various project phases. Project management, in turn, is intimately concerned with the software development methodology being used. Consequently, in order to produce accurate results when considering estimating techniques and productivity measurement, software metrics are often tied to the software development methodology.

A project is a temporary endeavor that has a defined beginning and end and is undertaken to meet unique, specific goals and objectives, generally for the purpose of causing required changes or adding value. The software product’s output is a product of some kind. Traditional waterfall software development methodologies fit well with this definition of a project. The concept of a beginning and end are essential to both the methodologies and the management of the project. Once a project is defined, software metrics may be gathered and applied to the overall measurement information. Project metrics are meaningless without well-defined projects.

Rapid Application Development
Software development methodologies were originally derived from some form of waterfall process, where one phase followed another. They began to evolve further in the 1990s, when Rapid Application Development (RAD) was developed by Dan Gielan and James Martin and gained popularity. RAD methodology uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. This generally enables RAD projects to be implemented in a shorter period of time.

There are several types of RAD methodologies, some of which are listed below. Although most of the methodologies foster the reuse of software, distributed development, and small team structure, many RAD practitioners recognize that there is no single “rapid” methodology that provides an order of magnitude of improvement over any other development methodology.

Application development using RAD generally favors smaller projects that can be developed in sizeable pieces. This has a considerable influence on the concept of a project, but agile, because of shorter release cycles and more rigorous definition, has an even greater impact.

Some of the “flavors” of RAD methodology include:

• Agile Software Development: Agile software development features extremely small release cycles by breaking up software projects into mini-increments. Real-time, face-to-face communication is ideal for agile software development. Documentation is developed when it needs to be developed, which may be at the completion of a project.

• Extreme Programming (XP): XP is a set of development practices, first defined by Kent Beck in the late 1990s, that features short iterations, close teamwork, and customer satisfaction. Although this terminology predates agile, it is now considered a form of agile.

• Joint Application Design/Development (JAD): JAD is closely related to RAD, the primary difference being that JAD emphasizes the crucial role of the customer, and customers are actively involved in design activities.

• Scrum: Like XP, Scrum terminology and definitions predate those of agile. Scrum is now considered one of the leading agile software development practices. Scrum development practices are reduced to a series of short iterations or sprints, in which teams are self-organized.

This article focuses on applying FPA to agile software development, but the same principles can be applied to all of the above methodologies.Agile Software Development
Although agile development traces its roots back as far as the first incremental development methods in the 1950s, in most circles, it’s considered the next evolutionary step of RAD. Most of the agile principles were developed, defined, and documented in the Agile Manifesto, published in 2001. The manifesto describes a type of RAD methodology that favors small projects with team-oriented development groups and close customer contact and involvement. Project management of agile projects consists mainly of monitoring and measuring progress toward goals.

Given this new direction, it is understandable why it might appear that there may be difficulties in applying traditional software measures to agile projects. When a project used to be clearly defined up front (in the planning and analysis phase) with a clear beginning and end, it was easy to identify points in the lifecycle where data collection could occur and measures could be created. The same can be done with projects utilizing agile methodologies, but the approach must be flexible.

Agile Software Development “Projects”
In order to gather and apply project-related software metrics for projects developed using an agile methodology, we must first define the concept of a project in this context. Regardless of what development methodology is used, a project is still defined as a temporary undertaking with a predetermined beginning and end with the purpose of bringing about a change or producing a product. For agile development, a project may consist of one or more “stories” or “sprints” that are required to produce this final result.

In agile projects, a user story is a high-level definition of a requirement containing enough information so that the team can produce an estimate of the effort and then develop and implement the functionality. Eventually, the story may become one of the main artifacts to use in function-point counting. A sprint is an incremental piece of work used by the Scrum practices as part of an agile methodology project.

What is included or excluded from a sprint (and therefore the function point count) is determined by the project manager as well as the customer. This article generally refers to a project as a series of sprints, although it is recognized that one sprint or story may make up an entire project. Once the project is defined in this way, project-related software metrics gathering may take place. Function point analysis may be performed at the completion of the agile project or at any point during its development, just as it would for any project.

Agile Software Development and Function Point Analysis
Story points are considered by agile developers and devotees as a method of measurement for agile projects. The rate or number of story points produced during a sprint or set of sprints is called the velocity. Although there is no industry standard method of measuring story points, some organizations may measure them the same way across projects, while others will vary.

FPA provides the base measurement of several metrics; it may be performed for a sprint or an entire project. For example, there may be requirements to add a new logical file, along with functions for maintaining and viewing the data, as well as a new report to the existing system functionality. If the entire project is counted, these functions would be considered together in one project function point count (this is also the approach used to count traditional waterfall methodology projects). Considering a sprint using agile methodology, the logical file, view, and maintenance functions may be added in one sprint and the report in another. If counts are performed for each sprint, it may be possible to add the results together for the total size, which is the same as the project count. This enables all of the stakeholders to be aware of the project’s size as well as how much effort the team is expending.

Function Point Analysis can indeed be used to measure agile projects. Consideration must be given to the way in which such projects are defined. In part two of this series, we will demonstrate the use of FPA in agile development through hands-on examples. Part three will expand on the FPA examples in order to show how the metrics are applied to produce productivity, quality, and estimation measurement information.