When counting function points for Agile projects, all of the IFPUG standard counting rules apply; the level of information and the intent for the use of that information is where the differences come in. For an Agile project, we typically execute one of two scenarios: counting at the project level or counting at the sprint level. The key deciding factor used to determine the appropriate counting scenario is when the new code will be delivered to the users.
Project-level analysis is performed at the same level of counting that is typically used in any waterfall project, where delivery of executable code is at the end of the project cycle. Counting at the project level is consistent with IFPUG guidelines – it is also the preferred method for those who have an existing function point process in place, as it provides an apples-to-apples comparison. Overall, the process is unchanged, everything continues as it always has.
In this scenario, individual sprints are counted as if each were an independent mini-project. In each sprint, we count the functions as features (stories) that have been delivered to the user by the end of that sprint. Any features (stories) that are still in progress and have been carried over into the next sprint are excluded from the count for that sprint. As expected, features are included in the sprint in which they are delivered.
Counting at the sprint level, in our experience, is not a common practice. This is particularly evident when a project-level function point program is in place. Comparison between existing project-level counts and sprint-level counts is not easily done; the sum of the parts (sprints) does not equal the whole (project). Within an Agile project, a single transaction may be touched and delivered as part of one or many sprints, resulting in what would be considered over counting, when comparing to a project-level count. Although they are not interchangeable, both scenarios are useful depending on the level of information desired.