QSM provides unparalleled support throughout the product acquisition, installation, and implementation process.
For nearly five decades, QSM has helped organizations bring data-driven discipline to software project estimation, tracking, and benchmarking. Our methodology and tools turn project complexity into measurable, defensible outcomes.
Function points (FPs) are proven to be effective and efficient units of measure for both agile/iterative and waterfall software deliveries. However, inconsistencies come to light when comparing FPs counted in agile/iterative development with those counted in waterfall or combination development — and those inconsistencies can create confusion for cost, productivity, and schedule evaluations that span multiple software delivery methods.
IFPUG’s definitions for such terms as “project,” “elementary process,” “consistent state,” and “enhancement” do not directly translate to agile/iterative delivery methods in which the term “project” is often interchanged with such terms as “sprint,” “iteration,” “release,” or “story map.” This paper seeks to marry IFPUG definitions with equivalent concepts in agile/iterative processes so as to create a basis for consistent comparison.
Functional size is a pre-requisite for estimating the cost, effort and duration of software development “projects” (labeled by IFPUG as development projects for the first “release” of a software product and enhancement projects for its subsequent adaptive maintenance and enhancement). Function points are a convenient and reliable common denominator of size and are often used as the basis for comparing project productivity (FP/effort), duration delivery (FP/elapsed time), maintainability (hours/FP), product quality (defect density) and other important aspects of software delivery.
With today’s IT landscape dotted with agile, iterative, spiral, waterfall and combination approaches to development, businesses are searching for the ultimate approach to delivering the right software (functionality- and quality-wise) at the lowest unit cost for the least amount of effort. But for estimation to succeed in this climate, we’ll need consistent FP definitions across all methods of software delivery.
Gone are the days when agile/iterative development methods were considered “rogue” and without structure; today, agile methods are held in high esteem, even in conservative software development shops where waterfall still prevails. Indeed, the penetration of agile in the IT marketplace has had numerous positive impacts, including:
Now, with both agile/iterative and waterfall methods at their disposal, businesses are searching for the optimal combination of talent, tools, techniques, cost, and schedule that will deliver good-enough quality software for a reasonable investment of time and money. But finding that “sweet spot” relies on measuring the same elements in the same ways across various delivery methods. And consistency in measurement depends on consistency of definitions and the application of measurement techniques, such as IFPUG Function Points.
We need to start by aligning the IFPUG definitions and then looking at how to apply them consistently to count FP on agile and waterfall deliveries alike.
IFPUG FP methodology (IFPUG 4.3.1) gives us guidance on how to count FP based on projects and the delivery of unique (and complete) elementary processes that leave the business in a consistent state. Agile/iterative techniques deliver software incrementally. Defining what constitutes a “project” and the delivery of an “elementary process” in agile/iterative is the KEY element for consistent function point counting across development approaches.1
Since FP counting of software development is meant to measure the size of the functional user requirements delivered via a project (development or enhancement), the methodology used to implement that functionality (be it agile/iterative, spiral waterfall, or any other development method) should have no effect on the size of the delivered software product. The application FP (also called the baseline or installed application FP size) is the same regardless of the delivery method used and can be measured consistently at the completion of any type of software delivery. Application FP counts are of secondary concern for this paper; the primary concern is defining what constitutes a “project” (either development or enhancement) in agile/iterative development.
Before we get into the issues and challenges of counting FP in an agile environment, let’s add a bit of strictness and consistency to a few of our terms:
For waterfall development, it is fairly easy to identify and count FP for discrete development and enhancement projects. “Release” and “project” are often used synonymously to refer to the scope of a self-contained software delivery.
For agile development, a “project” is not so easily identifiable. “Sprint” and “iteration” are used more often than “release,” and those terms are based on elapsed calendar time or work effort rather than functionality. “User stories” (or “use cases”) are used to describe functionality and are useful for identifying functional user requirements, but there is no requirement that they constitute an elementary process or that they leaves the business in a consistent state — both of which are required for FP. The notion of using “story points” (a sizing approach intended to quantify the relative size of a user story) as equivalent to FP (as suggested by a few agile advocates) is not feasible for the following reasons:
When functionality is delivered in discrete and well-defined construction projects, as is intended with waterfall-style deliveries, counting FP is easy and based on a single set of functional user requirements. Even when a subset of the overall features is delivered in one release and then enhanced in a later release, the discrete “chunks” of new/enhanced functionality make counting FP a straight-forward process using IFPUG methodology.
With traditional waterfall delivery, the terms “developed” and “delivered” are almost always used interchangeably. But in agile/iterative development, there is a difference between “developed software” (which is not yet ready for mass deployment) and “delivered software” (ready for full deployment).
Therefore, with agile/iterative forms of software delivery, counting the “delivered” functionality is not so easy. IFPUG (and other ISO conformant) functional size measurement techniques are counted based on complete elementary processes or functions that leave the business in a consistent state, not on parts thereof. A “function point” count consists of delivered (or anticipated to be delivered) functions that are whole business processes. Partially delivered functions that are incomplete and cannot support the business without further work would not typically be counted as “function points delivered.” For example, a business process such as create hotel reservation would not be an elementary process until a reservation is made and stored. If the first part of the reservation process was delivered in one sprint (such as checking the availability of a hotel for given dates) and the latter part was delivered subsequently (enter customer information and book reservation), FPs would be counted on the elementary process (both parts.)
At this point, you may be asking why we don’t just use the word “release” in place of the word “project” and be done with it.
Or, couldn’t we simply count up the delivered function points at the end of a “release” no matter how the software is developed, and then compare the productivity across releases to perform our estimates?
Actually, yes. This is absolutely the right way to go, but only if our definition of “release” can remain consistent across our various forms of delivery. For starters, we’ll have to determine the number of agile iterations or sprints that constitute a “release.” Let’s consider the following situations:
Diagram 1 Waterfall releases vs agile releases
Some would suggest that each sprint or iteration should count as a discretely countable functionality in FP; however, this approach would contradict FP definitions and concepts including:
Why would counting “sprints” violate these definitions? The answer is that a sprint, by definition, is based on elapsed time or work effort — not on functionality. Certainly user stories (and use cases) describe user functionality, but there is no requirement that they describe complete or self-contained functionality. Consider that two user stories for an airline reservation system might be written as:
a. Choose the flights on which you want a seatb. Pay for the reservation
Clearly these are two different steps in the sequence of steps needed to complete the airline reservation. But each one is NOT its own separate elementary processes they’re part of a single elementary process where both steps are needed to leave the business in a consistent state.
Further examples:
When we talk about implementing user stories or use cases, the assumption may be that each user story or use case equals at least one standalone and self-contained function. This is seldom the case. While the scope grows and morphs with each iteration or sprint, the requirements are often progressively elaborated. This means that one “functional user requirement” may span multiple user stories or use cases — especially if it is a complex one. Thus, the application may not satisfy the full user requirement for a process or transaction until after a set of sprints is implemented.
A full agile software development implemented in a series of two- to six-week sprints will deliver functionality in a piece by piece fashion. It may not be easy to determine/predict when the functionality will actually be delivered, especially once the IFPUG definitions for “elementary process” and “leaving the business in a consistent state” are taken into account.
Using the home building analogy, agile development is similar to pouring the foundation and building rooms a bit at a time, as the overall floor plan eventually comes into being. When a home is constructed in this manner, it is not ready to be occupied until the rooms are finished and a roof covers the structure. In agile development, functionality is typically delivered partially — in sprints — and it isn’t until several sprints are delivered that the business can begin to actually use the software. Yet there is a tendency to assume that sprints and iterations are akin to a new development project for the first sprint and enhancement projects for each sprint thereafter.
The challenge to counting FP on agile projects lies in determining which functional user requirements have been satisfied (and when they are satisfied) by the software delivery.
For instance, if a function is “delivered” in a sprint (i.e., we count FP for the initial sprint, assuming that the user story completely describes an elementary, self-contained, and complete business function), and subsequently enhanced in a second sprint, was the original function:
a. Incomplete (i.e., the elementary process was NOT fully delivered in the first sprint) — and we shouldn’t have counted/taken credit for FP in the first sprint?
b. Complete at the time of the first sprint but now enhanced due to changing requirement — and we should count delivered FP for sprint #1 and count the entire transaction’s FP a second time for sprint #2?
c. Flawed in the first sprint — therefore the FP counted in sprint #1 should not be recounted in sprint #2 (because sprint #2 was only corrective maintenance)
d. Some other variation?
AND waterfall development) are the same. The actual size of the installed application baseline (FP installed) is — or should be — the same, regardless of HOW the software is developed.
When does the delineation of FP across sprints become an issue? (Or, why is it important to count delivered FP in a consistent manner regardless of development methodology between agile and waterfall projects?)
There are two significant situations where the FP “delivery” is critical to businesses:
Therein lies the dilemma and the challenge in using function points on agile projects — it is problematic to credit agile projects that deliver same completed functionality (i.e., complete elementary processes leaving the business in a consistent state) with having produced MORE functionality than waterfall projects!
To recap, let’s look at one example using the two different methods:
Waterfall software delivery: The business needs a new customer service application where the final installed software will equal 1000 FP. Through negotiation and agreement, three phases/projects are outlined, each of which delivers working software in production.
Agile development: The business needs a new customer service application delivered using an agile approach. User stories are iteratively documented and a series of 2-week sprints is agreed upon to allow developers and the business to discover the requirements and define them as they go. Twenty-five different sprints are worked on over a year period, and at the end of the “project(s)” the installed baseline software is 1000 FP.
The following list of recommendations is provided to increase consistency across the various forms of software delivery:
Comparative and consistent FP counts across various development “projects” can be done through consistent terminology, and the application of FP rules. Being careful not to size “bits” of functionality partially delivered, and instead grouping use cases and user stories into elementary processes according to IFPUG 4.3.1 will go a long way to creating consistent FP counts.
1 The reader is encouraged to refer to IFPUG’s Counting Practices Manual (CPM) 4.3.1 for information regarding definitions for terms used throughout this piece of literature.