Usually, the size of agile software projects is defined using Story Points. As you know, they are specific to each organization or development team. The biggest issue here is consistency. Indeed, it is impossible to compare the work of different teams or projects.
Function Points have been used for decades to measure the size and then estimate the cost of software projects. There are pros and cons to the use of Function Points to size Agile software projects.
Advantages of Function Points for Agile Software projects
Function Points provide successful estimates of software development projects for several reasons. The main one being the decomposition of the perimeter. It allows to take into account the share of overlapping code.
The biggest advantage of that sizing method, is that it is an internationally admitted standard. It is then consistent and repeatable, which is essential to software estimation. It is actually precisely for that reason that that standard was created and adopted by many companies worldwide. In fact, there are several Function Point counting methods (IFPUG, COSMIC, etc.), but they are quite similar.
When it comes to adopting Function Points, the main challenge for agile development teams is to accept that method. Agile teams tend to see Function Points as “old fashioned” and think they are not compatible with agile projects.
Agile teams probably will not use Function Point counts for any purpose beyond the release estimate, so it’s not considered as part of the agile method. Above all, epics and stories do not match the decomposition of the scope of the project the Function Point counting asks for. You cannot count the number of Function Points of each story and add them up hoping to get the size of the project. Actually, the elements of the scope that are weighted in Function Points may overlap multiple stories. You may mitigate that phenomenon by counting the Function Points in parallel with Story Points for iteration planning. The use of Function Points is then limited to estimation release and overall progress tracking. Although Function Points may have been used in the case of agile development, Function Point sizes are rarely recalculated at the end of a project.
Challenges of using Function Points for Agile Software Projects
Sizing agile projects in Function Points comes with two main challenges. The first one is dealing with emergent requirements. The second one is the lack of scope details during the early stages of the project. This is the issue addressed by the “Big Rock Sizing” method. But the latter generates specific issues that must be dealt with when using Function Points.
Function Point counting requires a level of detail concerning the requirements that is rarely available early on. For example, when counting Function Points, you count the data bases you expect to use. Then, you assign Function Points based on the approximate number of data elements.
In an agile project, you will not have those details early on. In some cases, you can take a smart guess. If you’re building an airline reservation site, you know you’ll have a data base for airports, for flights, for available seats, for reservations, and several others. But the complete list of data bases will evolve as the project goes on. The big rocks are refined iteration by iteration. Even in the case when you can guess, you will not be able to guess the number of elements to use when assigning Function Points. Forcing the team to think about these details early goes against the main agile technique of emergent requirements. Even the fact of “taking a good guess” may equivocate the team later on, when detailed decisions are needed.
How to adress those challenges?
The members of the Agile Round Table came up with two ways to attenuate that problem.
The first was the use of “Function Points Lite,” as one member of the Round Table called it. Instead of a formal Function Point Count weighting each element based on its detailed complexity, you assign an average complexity to each element. You can also count the obvious elements without biasing future emergent requirements and buffer the count to deal with the less obvious elements.
The second idea was “counting on the side.” It mitigates the team’s resistance to using Function Points in their day to day activities. It is particularly useful for progress tracking and completion forecast. An initial Function Point Count is conducted based on the high-level scope (perhaps using “Function Point Lite”). Then, as the scope is refined by breaking epics down into stories, a separate Function Point count is maintained and modified as the backlog is groomed.
Source Lines of Code for Agile Estimation
The end product of agile projects, like any other software development project, is code. Measuring that code by counting the number of lines gives a concrete size of the project. Unlike Function Points and Story Points, there is a standard definition of a single source line of code, even though it may be surprisingly complex.
Counting the source lines of code fell out of favor with development teams long before agile methods became popular. There are many reasons for this, some are good, some are more emotional than logical. Counting code is a viable way to compare the size of projects. It is perhaps the best way to get standardized data from many different sources. It is particularly valuable to compare your organization’s projects to industry data. It is independent of the way the scope of the project is expressed (e.g. epics and stories vs. the breakdown used by Function Point counting). Counting finished lines of code allows you to compare projects developed with agile methods to projects developed other ways.
The main inconvenient of using code counts for early estimation is not specific to agile methods. Since it’s not widely used for any purpose other than estimations, the project team members are inexperienced at counting total code. Ask most developers, “how many lines of code do you think that will take?” and you’ll be lucky if you just get a blank stare.
To count the code of completed projects, you can use automated code counters analyzing the code files, or the version control system your team may use. Thus, you can get code counts “after the fact” you can use to calibrate your estimates using other size measures, as we described earlier in this paper.
Summary
As with projects built using other methods, Function Points may be consistently applied to agile software projects since it is an international standard. However, agile teams may be reluctant to use Function Points since they seem old fashioned. Above all, the lack of detailed requirements early in a project challenges a rigorous Function Point counting.
Counting the source lines of code is a concrete measure that can be used consistently, and may help compare your projects to industry data. You can automate the sizing of completed projects to get a good historical data base for future estimates. However, the lack of experience in this measure makes it difficult to use in advance when estimating a new project. Hence, the need to call on experts in the field or acquire a tool that will automate that process for you.
