Blog

Too often we find ourselves driving the same route, simply out of habit. The road most definitely gets us where we want to go; it is efficient, relatively traffic-free and possibly the best way of getting from Point A to Point B. But, after hitting a construction zone one too many times, we start to wonder if there is a better route to take.

Yes, this is still a blog about the software industry! I recently encountered a situation that made me remember the need for carefully planning the path to your destination. I am a Certified Function Point Specialist (CFPS). That means that I work with clients in to size their software in support of their metrics program. In this case I was working on a new application being added to the customer’s portfolio. The development organization made the assumption that the existing measurement system would produce the expected results, but without the due diligence to validate that assumption. Eventually, it was too late to take a detour.

As the adage states, an ounce of prevention is worth a pound of cure. It is important to take the time to plan your route when developing new software or incorporating a new software package into an existing portfolio. Here are some things to consider:

• Is the SDLC appropriate for the project? Is Agile the right way to go or should we consider traditional waterfall – or something in between?
• Does the design approach follow the architectural standards of the organization? Is that design appropriate for this project? If not, should we consider requesting modification?
• Is the estimation approach going to yield accurate estimates in this case? What parameters must be modified to ensure accuracy?
• Have the risks been identified and appropriately planned for?
• Is the development team up to the challenge? Is education needed or should the team be augmented with additional skills and experience?
• Is the test strategy adequate for the project needs?
• How will success be measured? Do the existing measurements of success work for this project?

If you take the time to evaluate these aspects of the project, you’re more likely to take the right path in the first place. Avoid going in the wrong direction or having to take detours along the way – prepare!

Toni Ramos
Certified Function Point Specialist (CFPS)

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

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.

Sprint Level

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.

Summary

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.

Toni Ramos
CFPS