From the very beginning, all participants should start to form some expectation regarding the size of the application to be estimated. At the top of the post is the size distribution of new development projects. The size distribution is expressed in IFPUG function points. The methodology presented here uses IFPUG sizing measures. At this point, there is not enough industry experience to present a similar distribution for SNAP points. Even if there was, function points would still be the best way to express the size of an application that is about to be built. SNAP points become more important when estimating the schedule and effort for projects that have changes in functionality, such as enhancement projects. In any case, The sizing methodology presented here will take into account both function points and SNAP points.
if an applications is 50 function points or less, it should simply be assigned to an agile team and they should handle any estimating and reporting. The initial team size should be based on management’s experience with similar applications. Team size can be adjusted in future iterations. At the other extreme, only 10% of the projects studied had function point counts that exceeded 2,000. There is simply not enough experience with these larger applications to proceed without extra caution. When an estimator is convinced that a project is more than 2,000 function points in size, the possibility of dividing the project into separate components should be considered. Otherwise, the process can still be used, but additional care must be taken to insure functionality is not being missed. These huge projects can almost never be done by a single agile team.
According to industry practice, establishing scope and boundary is a must for any estimating exercise. Since this process is basically function/SNAP point based, it made sense to use the standard IFPUG definitions for these attributes. Scope and boundary rules are basically the same for both function points and SNAP points. The first step it to draft the scope and boundary of the application to be estimated. The scope and boundary may change during the estimating process. This may be the result of better understanding of the project or a change in scope. When this happens, the estimating process has to be reworked.
Prior to defining the scope and boundary, the purpose and type of assessment must be determined. This process was developed with a certain purpose and type in mind. The purpose of any assessment is to estimate the size of an application to be developed so that the size can be fed into an estimating model. The size will include both functional and non-functional requirements. All agile application development efforts involve taking some software and converting it into some other software with additional or changed capabilities. This type of assessment is an enhancement project. New development can be treated as a special case of enhancement. In new development, there is no existing capability to begin with. In days of old, the waterfall methodologies favored this special case of new development. You began with nothing and continually transformed models until you ended up with a completed application. For example, you did analysis and ended up with a data flow diagram of the entire system to be built. Then you transformed that into a structure chart to show all the components to be built. Then you coded the design to have a system. That was classic new development. In agile development, you are continually transforming working software from one form into another. A simple release is built that contains a workable subset of requirements. Then, the attributes of that release are changed and augmented to produce the next release of the software. It is basically software development by continual enhancement. Fortunately, this approach also works if the team is tasked with enhancing an existing piece of software that they did not build.
According to the IFPUG Counting Practices Manual (CPM), the scope “defines a subset of the software being sized.” It identifies which functions will be included in the size so as to provide the best estimate. A project might only be enhancing certain portions of a system. There may be reusable components that will supply some of the functionality to be delivered. All of this must be considered in the scope. For people using the IFPUG sizing methodologies, sizing can be complicated. For people using the process outlined here, it is fairly straight forward. The scope includes any existing software attributes that will be changed and any new attributes that will be added. People familiar with IFPUG methodologies may ask about deleted attributes. Most estimating models ignore deleted attributes. They are ignored here.
The CPM states that the boundary “defines what is external to the application.” If the application being built must interact with other applications, then these applications are outside of the boundary of the one being developed. People who use the application are outside the boundary of the application. The bad news is that establishing boundaries can be complicated. For example, is there a boundary around Microsoft Office? Or, is the boundary around Excel, Word , PowerPoint, etc.? How about QuickBooks? It seems like there should be a single boundary around QuickBooks. However, there are several versions of QuickBooks. There are several for the PC that have extended functionality. There is one for the Mac. There is a version that only works on the web. Some of them probably share portions of each other’s code. Where does the boundary get drawn? Fortunately, there are two pieces of good news. The first is that when using this process, the boundary is usually drawn around the attributes of the application that will be changed and includes the things that will be added. Sometimes, there will be changes made to multiple applications. In that case a boundary will be drawn around each. Who decides and how do they do it. This is the second piece of good news. It is the users, and probably the product owner, that is most qualified to make this determination. They make it by deciding how users view the software they are using. For example, do they think they are using Microsoft Office or Microsoft Excel? It is probably the latter and that will drive their boundary decisions.
The scope and boundary may emerge from a study of the initial stories that define an application. Otherwise, they must be established by some other collaboration between the estimator(s) and the stake holder(s) of the application. The definitions of scope and boundary for this process are completely consistent with those found it the IFPUG CPM. Of course, these definitions of scope and boundary are probably generic enough to be used with virtually any sizing measure.
People who are familiar with the SNAP process may be surprised that no mention has been made of partitions. Partitions are identified as part of this process. However, they are not identified at this time.