This is a manual for semiclassical agile estimating. It explains every rule and presents every calculation required to use the methodology. It is free and will remain free. However, it is not intended to be a instructional document. It does not explain how this technique meshes with other agile techniques. There are no case studies. It does not explain how it might be implemented.

Introduction

• Semiclassical Estimating for Agile Projects
• Overview of Semiclassical Estimating
• Concepts and Capabilities of Function Point Estimating of Initial User Stories
• Concepts and Capabilities of SNAP to Size Changes Between Releases
• Use the COCOMO Suite to Estimate Staffing and Schedule for Agile Projects

Set Up for Sizing

• Draft Scope and Boundary
• Identify Locations
• Identify Roles
• Identify Partitions
• Identify Code Tables
• Counting Batch Processes

Size New Processes and Data Groups

• Adding an Input Screen
• Adding an Output Screen
• Adding an Elementary Process
• Adding Data Groups
• Add a Typical Process
• Add a General or Marco Process
• Calculating the Size of the First Release

Estimate and Schedule the First Release

• Transforming Size into Schedule and Effort
• Cost Drivers – Scale Factors
• Cost Drivers – Effort Multipliers
• Using COPSEMO and CORADMO on Agile Projects
• Transforming Schedule and Effort into a Plan

Size and Estimate Subsequent Releases

• Changing an Input Screen
• Changing an Output Screen
• Changing an Elementary Process
• User Data Configuration Files to Add Value
• Calculating Size, Effort and Schedule for Nth Release

The first release of a new development project consists entirely of added functionality. After that, each release usually consists of added functionality and changes to existing functionality. Care must be taken in deciding what is an add vs. a change. For example, if your application allows you to store information on sales people and you update it to capture information regarding products, then that is added functionality. If you capture information about your sales people without their birthdays but decide to begin capturing birth days, that is a change to the elementary processes associated with maintaining information on sales people. There was probably a user story like “as a manager, I can maintain information on my sales people.” An estimator would have identified elementary processes for adding sales person information, changing sales person information, deleting sales person information and displaying sales person information.

In subsequent releases after the first one, function points are still the best way to measure project size for functionality being added. Releases after the first release, but prior to the minimum viable product (MVP), tend to be made up primarily of added functionality. All of the rules discussed in Calculating the Size of the First Release are applicable here. Some care must be taken when adding data groups. Sometimes a data group will appear to be new but will be, in fact, part of an existing data group. For example, if an application might already have data groups for resources, i.e. people, and projects. If this release is introducing assignments, the question is whether this is a new data group. If the assignments are simply a relationship between people and projects, then it should probably be treated as a change to both of these existing data groups. It should be evaluated using SNAP points. If an assignment can exist independently of any project, then it is probably a separate data group that is being added at this time. It is added using function points. If neither of these extremes is the case, then it is the estimator’s job to decide whether it is new or change functionality and handle it accordingly.

When counting SNAP points, begin by identifying the elementary processes that will undergo change. This process may begin by identifying the user stories that will change. These stories will have elementary processes associated with them. It is possible that some of the elementary processes associated with a changed user stories will not change. For example, there may be a story such as “as a manager, I can maintain employee information.” This story might have elementary processes to add, change, delete and list employee information. Even if the user story changes, it is possible that the “delete employee information” process will remain unchanged. Once the set of elementary processes that are changing is identified, use the rules that were described in Changing an Elementary Process to size the changes in SNAP points. The guidelines are repeated here for convenience:

There are three items that are counted using SNAP that are not captured strictly from the elementary processes. The first is data configuration files. Counting these was explained in User Data Configuration Files to Add Value. A summary of this is:

The second item is based on the number of batch files. Rules for counting these were given in Counting Batch Processes. A summary is:

The third item is based on the application’s help system. When elementary processes are added to a system, they usually have help associated with them. This was discussed in Calculating the Size of the First Release. As additional elementary processes are added to an application, more help information is added to the application. This is considered to be part of the process and is not estimated separately. When elementary processes are changed, the help information will change. Often, subsequent releases will introduce help in levels that were not provided before. For example, one release may produce a report, but a later release might introduce help that would explain how to interpret that report. Cases like these should be estimated using SNAP points. When counting SNAP points, anything that was covered by the function point count should not be considered. Here, we are not counting; we are estimating! Any time that an estimator thinks that some of the help will be a significant separate effort, it should be considered. First, enumerate the help objects. Examples of help objects would include:

• Text explaining how to interpret a report,
• Data Element Types (DETs) that might be on an input form,
• Explanations of menu item,
• Any static web page,
• A link to an explanation of a password that might occur on a “Change Password” screen,
• Text explaining the purpose of an input screen,
• A link to some other multimedia item such as a movie, or
• The text of a FAQ.

Count the number of help objects and divide by 16 to arrive at the number of SNAP points. If any of the help objects utilize a screen print, then add an additional 2 SNAP points.

Remember that some items may be beyond the scope of a software estimate. For example, if a web site for traders contains a course on how to do technical analysis of stock price movements, the effort to develop this course is best estimated using some other approach. The same might be true for a static web page. Taking some product information and putting on a web page might be comparatively simple. Developing a web page explaining a company’s mission and vision might take a long time for a start-up that has not addressed these issues yet.

Function points and SNAP points are consumer measures. They are obviously measures of size. They take a user’s point of view. A user considering an application that maintains five logical files will probably think that it is smaller than one that maintains 10. Obviously, there are other considerations. If the first application has 50 reports and the second has 10 then comparing the relative sizes becomes more difficult for a user. Projects make the situation more complicated. It is difficult to compare a project that adds a logical file and the maintenance transactions to a project that changes the format of 10 different existing transactions. The function points of one cannot be compared or added to those of the other. This situation is not particular to software. The United States Postal Service (USPS) charges for the delivery of packages based on their size. Size is a function of both weight and the dimensions of the package. However, they cannot be combined. A 12 ounce package in a 10 inch by 12 inch envelope cannot be interchanged with a 24 ounce package in a 5 inch by 6 inch envelope. The weight and dimensions are simply two different attributes that cannot be compared, interchanged or added together.

The USPS has found a way to charge for shipping that considers weight, dimensions and distance. There is no easy formula. There are tables that consider these attributes in order to arrive at a shipping price. In the case of USPS, this might also be considered a producer measure. It should be reflecting the cost that it actually takes USPS to perform this effort. Traditionally, the producer measure in software development was the Source Line of Code (SLOC). It represents the effort that developers are actually putting into the project. This is still the case except cases where there is significant amounts of screen painting and other software development that does not involve writing lines of code. Just like USPS blending weight and dimensions to calculate prices, function points and SNAP points must be blended to arrive at a size measure. This is complicated by the fact that function points are usually used to measure the size of adding new functionality while SNAP points are usually used to measure the size of changes to elementary business processes. Project size incorporates both. After reviewing projects that involved both types of functions and measures, it appears that the best blending of size would be to take function points and add .858 times the number of SNAP points to come up with a blended size.

Transforming Size into Schedule and Effort described how to do this for the first release. The approach is exactly the same except that SNAP points are added to the equations. They are summarized here.

The effort in person-months can be given by the equation RAD EFF PM = 4.46 * SIZE ^ E * Product of 21 Cost Drivers. E = .91 + .01 * Sum of 5 Scale Factors. The cost drivers and scale factors were described in Cost Drivers – Effort Multipliers and Cost Drivers – Scale Factors. The SIZE is determined by the equation SIZE = Sum for each Language Level ((Number of function points + .858 * Number of SNAP points) * Percentage of functionality implemented using languages at that level * 320 / Language Level) / 1000. Language level was described in Transforming Size into Schedule and Effort and is not repeated here.

The next thing to calculate is the calendar time that this application should require. The primary driver is the effort required. Calendar time is a function of the effort but it is not a continuous function. The equations for calendar time are different depending upon the size of the project. In this case, the project size is measured in person months of effort. The effort figure from above could have been used, but for consistency with the COCOMO suite, a quantity called PMnoSCED is used. PMnoSCED is the effort figure from above / the product of the last 5 cost drivers / 1.43. PMnoSCED is based solely on COCOMO, which uses only the first 16 cost drivers. The value of 1.43 is the extra effort that is required for rapid delivery. As far as the formula is concerned, it is the value of SCED. Once this value is determined, the calendar time is determined by one of these alternatives:

• If the project is small, based on the value of PMnoSCED being less than or equal to 16 staff months, then the number of calendar months, called RAD EFF M, is equal to 1.125 * SQRT(PMnoSCED) * product of the last 5 cost drivers. The last cost driver has a different value for schedule than for effort. In any case, this value will be of no surprise to traditional project managers. It was common wisdom to staff a project by using the square root. For example, a 9 staff month project would be performed by 3 people in 3 months. The truth is that small projects can often be planned by identifying tasks and assigning people to them. The project plan becomes the estimate.
• If the project is large, based on the value of PMnoSCED being greater than or equal to 64 staff months, then RAD EFF M is equal to 3.1 * PMnoSCED ^ (.28 + .002 * the sum of 5 scale factors) * product of the last 5 cost drivers. This is delivery time from COCOMO, post processed by the CORADMO cost drivers. This is not surprising; COCOMO was built with large projects in mind.
• If the project has a value of PMnoSCED between 16 and 64 staff months, then the number of months is based on a linear interpolation between the number of months between the delivery time for a 16 staff month project and a 64 staff month project. It is based on this value, because the result is still post processed by the CORADMO cost drivers. Without considering this post processing, a 16 staff month process will be completed in 4 calendar months. The delivery time for a 64 staff month project, a value that can be referred to as Mof64 is given by 2.75 * 64^ (.002 * sum of 5 scale factors). The delivery time for the project, RAD EFF M, is equal to 1.125 * ((M of 64 – 4) / 48 * PMnoSCED) + (4 – 16 * (Mof64 – 4) / 48)) * the product of the last 5 cost drivers.

It was described how schedule and effort predictions were mapped into a project plan in Transforming Schedule and Effort into a Plan. The second through the Nth release is done in the same way as the first. The key to understanding this process is to consider the staffing level and the project backlog. Usually, the team is staffed higher than is necessary to produce the next release. This is because, in addition to working on the next release, the team is also working to produce the MVP. Another way to look at this is from the perspective of the backlog. In the beginning, the backlog is full of items that are necessary for the MVP. Only a portion of them are addressed by any one iteration or sprint. However, the project team should be working on additional backlog items so that it is positioned to deliver the MVP after a few releases. Theoretically, the backlog will be empty when the release that produces the MVP is done. In reality, the backlog will probably contain changes that seem desirable for the application but are not necessary to incorporate into the MVP.

The COCOMO Suite is used to transform software size into the amount of time and effort that would be required to implement it. When projects were performed using the waterfall approach, once the schedule and effort were established, the planning was fairly automatic. Development was broken into phases, the phases were broken into tasks and the project was executed. That was the theory. In practice, it usually involved some false starts, rework and assignment of blame. The situation is different with agile development.

In agile development, the team has to have three different targets in mind at all times. The first target to consider is the overall completion date. However, useful software never seems to be done. WordPress is still evolving. The same is true of the Microsoft Office suite. Therefore, software should debut as a minimum viable product (MVP). The agile/lean software development revolution has been felt in many areas. One of these is marketing. In marketing, the MVP is the simplest version of a product that can be placed into the hands of a customer. The customer must feel that it is valuable but it may not have all of the features that will eventually be incorporated into the product. In new product development, this gives the company an income stream. More important, the MVP opens up a dialogue where the customers and prospective customers can direct future versions of the product. Customers can choose the features that are the most important to them. It provides a product development direction.

The concept of an MVP is not just for companies developing products for external customers. It applies to in-house developers who are building software for other departments. The sooner that something usable can be placed in the hands of fellow employees, the sooner the business value of that software will be felt by the organization. The same is true for customer feedback. Agile development welcomes change, even when it comes late in development. This is one of the 12 principles of agile development. Once software is in the hands of any users, internal or external, they will see problems and opportunities that were unanticipated when the initial user stories were being drafted.

According to the principles behind the agile manifesto, the agile team should “deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” This is a release. In the diagram above, the MVP is delivered in two releases. This is simply an example. The MVP might be done in one release or several. The releases might be require different amounts of time as long as they are each two months or less.

A release results in a working application. Releases have a psychological impact. A release lets the customer know that work is being done. The release sometimes has a business benefit. For example, a release might let customers enter code or business reference data into an application. This data might then be used by future releases. The first release is also important to the agile team. From a psychological point of view, it proves to themselves and their customers that they can work together and accomplish something. There is also a technical component to the first release. It allows the team to debug the tools and techniques that they are using to build their application from the development environment to the production environment.

It is great when the MVP can be delivered in a single release. It is also uncommon. It is critical that MVP not be forced into a single release. If the MVP is so restricted in terms of functionality that is is not truly valuable to a customer, then those prospective customers will be turned off and burned off. There may not be an opportunity to approach them with an improved product. Furthermore, the underpowered MVP may allow competitors to know about the product. They may see some unique idea that they can capitalize on. One of them may have the ability to take that product idea and implement it in a way that satisfies these customers. It is important to realize that everyone has customers and competitors. This is obvious in a product development company. For in-house developers, their customers are the fellow employees that will use the application. In-house developers also have competitors. These include firms that want to sell software that comes close to meeting the needs of organization, software developers who are willing to develop the same software, end-user groups that think they can better meet the requirements of the application. If customers become frustrated, they may turn to one of these alternatives.

Once it is discovered that the MVP requires more than two months to complete, then a new first release must be estimated. The stories and elementary processes that were estimated should be examined. A subset of these can be selected for the release. In some cases, a user story will stay in the release but it will be implemented in a simpler form. This may mean that some of its elementary processes associated with that user story are put on hold. This subset is estimated. It will probably be more or less than the two month target. Based on this, more functionality may have to be removed or it may be decided that some functionality should be reinserted. This process of changing functionality and re-estimating is iterative. It continues until a set of functionality is identified that can be implemented in the timeframe of a release.

The lowest level of planning is the iteration level. When Scrum is being used, these are called sprints. Organizations usually decide on a standard amount of calendar time for their iterations. This can vary between one week and one month. Two week iterations are common. The entire agile team is involved. Therefore, the amount of time and effort are fixed. There is some question regarding how much functionality will be implemented. User stories will be assigned to an iteration. The project owner is responsible for establishing the priority of user stories. The project team usually uses story points and velocity to decide how which stories will be worked on. Even if the selected stories are not completed, the iteration ends at the end of the iteration length. If some stories were not completed, they get added to the backlog of stories to worked on during subsequent releases. If all of the stories are completed, then the backlog is checked for additional stories to work on. The sprint does not complete early.

There are many activities and meetings that occur during each iteration. They are usually specified by the organization and the particular variant of agile that is in use. Stand up meetings each morning are common. Review meetings at the end of the iteration are also common. Obviously, all of these activities need to be done and are automatically included in any iteration planning. Background grooming is one of these activities. While working on an iteration, the team will develop a better understanding of the user stories they are working on as well as some of the stories that are in the Product Background. Based on this new understanding, elementary processes may be added to or deleted from some of these stories. The same is the case for logical files. When this happens, it may impact the estimates that were done for the release or the MVP. If the impact is significant, new estimates of schedule or cost will have to be presented to stakeholders.

In the first release of a new development project, the only thing to base an estimate on is the initial user stories. These stories often contain keywords that can be used to generate an initial rough estimate. The keywords have already been discussed in Add a General or Marco Process and Adding an Elementary Process. The keywords are repeated here but they are grouped together in alphabetical order for ease of use.

The words that make up the user stories are searched to see if any are in the lists above. If one is found, then the function point value is used for the size estimate. If more than one is found, then the largest function point value is chosen. If none is found, then the user story must be decomposed to one or more of the processes described in the remainder of this post.

There are pros and cons of basing the estimate on the keywords in the user stories. The pro is that it is quick and easy. With no real analysis, it is possible to get a very rough estimate of size. This early estimate can alert people to any misconceptions regarding the size of a project. It gets people thinking about the proper order of magnitude of the project. There are many cons regarding this approach. First, it does not always work. Many of the user stories may have none of the above keywords. They will have to be further analyzed in order for their size to be estimated. Even when user stories contain one or more of the keywords, the estimate of size can turn out to be very inaccurate. It would be irresponsible to plan a project simply based on user story keywords.

When estimating the first release of a new development project, all of the functionality is being added. There will probably be several iterations (sprints) that must be performed to deliver this release. Some of these iterations may revisit some piece of functionality. However, the estimate is being performed for the release. Revisiting functionality and refactoring in general are not separately estimated. They are part of the work necessary to deliver the release. Therefore, the function point counts of the new functionality are the only relevant measure of software size.

Occasionally, a project will be to make changes to an existing application. It may be that a legacy application is being modernized or enhanced. Another possibility is that some software has been purchased with the idea of enhancing it. These cases are not new development. They are enhancements. They have to be estimated like the subsequent releases of a new development project. Since they involve both new and changed functionality, their size will be measured in both function points and SNAP points. It is as if someone else did not first release of the application and that that time is not being estimated for this project. However, the elementary processes that are being modified as part of this release must be captured and used to generate the SNAP estimates. Any new functionality will be tracked and estimated in terms of function points.

User stories are usually decomposed into typical, general and macro processes. These processes were describe in Add a Typical Process and Add a General or Marco Process. In many ways, typical and general processes represent the sweet spot in estimating based on initial user stories. These stories often lack the details necessary to get down the the elementary process level. A repeat of the typical process description and weights follows:

If there is an initial user story like “As a customer service representative, I can maintain a customer profile,” there is a question of what elementary processes might be included. Would the CSR be able to delete a customer profile? Would there be any type of report produced, like a list of the customers whose profiles were altered? These decisions might not be made until the story was being implemented. In the meantime, assuming that the story was a medium size typical process with 21.1 function points might be as precise an estimate as possible. Besides, the time that would be required to make a more precise decision might be better spent on other activities that a product owner has to perform.

A repeat of the general and macro process descriptions and weights follows:

Epic stories often correspond to general processes. There are times when an input file of many different transaction types are being processed and this becomes a general process whose size depends upon the number of different transaction types involved. Macro processes are usually based on previous experience that the organization has. For example, the organization may have several systems where it was required to assign a credit limit to a person or organization. Each of these had between 5 and 7 general processes. Then this macro process would be estimated as 285.9 function points. Care must be taken when using macro process because two processes may seem similar but be very different.

Sometimes the best approach is to decompose the user stories into elementary processes. This is not an all or nothing decision. Some stories are obviously typical processes and should be estimated as such. Others should be broken into elementary processes using the guidance discussed in Adding an Input Screen, Adding an Output Screen and Adding an Elementary Process. Often, a user story will contain several elementary processes. The following steps are used to assign weights to each one:

1. Decide whether the process is an input or an output. The inputs are considered generic external inputs and estimated at 4.2 function points. Occasionally, it is not obvious whether the process is an input or an output. In these cases estimate the process as an unspecified process with a weight of 4.4 function points.
2. If the process is an output, then decide whether it is an external output or an external query. Generic outputs have a weight of 5.2 function points; generic queries, 3.9. It is not always possible to decide based on the initial user stories. Outputs have calculations or update internal logical files. It is usually possible to make an educated guess. The few times that such guesses are wrong will tend to cancel out. If there is no basis for a guess, then estimate the process as an unspecified generic output with a function point weight of 4.6.

Any of these estimates external inputs, external outputs and external queries can be made more precise by assigning function points based in the number of file types referenced (FTRs) and data element types (DETs). This process was explained in the posts referred to above. However, it seldom makes sense to attempt to go that far. The FTRs and DETs can not usually be ascertained based on the initial user stories. Even if it were possible to find this information out, the time spent counting function points would be better spent on other estimating or system development tasks.

Data groups must also be identified and counted. In user stories, the nouns usually correspond to a data group. For example, “As a trader, I can log my trades.” would probably indicate that there was a Trades data group. It would probably be an ILF. Unspecified ILFs can be estimated as 7.7 function points. The size of an ILF can be counted if the number of DETs and record element types (RETs) are known. They seldom are based on the initial user stories. Once again, it is usually not worth the time and effort of generating an exact count.

If there is a story “As an investor, I can have a portfolio valuation based on current stock prices,” then there are two groups of data. Portfolios is probably an ILF. Stock Prices may be an ILF or an EIF based upon whether it is being maintained by the application being developed or another application. If it is an EIF, it will be difficult to estimate because it might contain more than one ILF in the application that is maintaining it. There might be a separate logical file to maintain stock split information. If Stock Prices was a single EIF, it should be estimated as a Unspecified EIF with a function point weight of 5.4. If the estimator thinks that it consists of a couple of logical files, then the table below would be used to estimate it as a general data group with a weight of 21.4 function points.

Size	Unspecified Logical Files	Function Points
Small	2-4	21.4
Medium	5-8	46.3
Large	9-13	78.3

When sizing the data groups, it is critical not to double count. There may be several user stories that reference Portfolios but there is only one logical file or data group. There is not one for each file reference.

If an application has a help capability, then it should be considered an add in the first release. The help capability will be estimated as a 5 (a simple external interface) + 3 (a simple external inquiry) times the number of levels of help. For example, if there was help for an entire screen and also for each individual field on the screen, then the size of the help function would be 5 + 3 * 2 = 11 function points.

Once all of the above items have been identified and sized in function points, sizing the project is a matter of adding up the function points. Size is a tricky concept. The number of function points is a measure of functional size to the users of the application. This size must be weighted by the development tools, i.e. computer language, being used for implementation. There are also other factors to consider beyond the number of function points but this is the main driver of any estimate being produced.

Applications maintain data. An order entry system would obviously have a file with orders in it. This order file would be functional. It would be related to the data that was used and maintained by the system. However, there are other types of files that are found in an application. These are technical. They often make up 50% of the physical files in an application. They are referred to as code tables. They usually have two columns: code and description. An example of this might be a file of airport abbreviations. Many travel related applications have a file or table with airport names and their abbreviations. When a user enters an airport name, that entry must be one of the abbreviations in that table. This makes practical sense. If a user wanted to enter Newark Liberty International Airport, EWR must be used. Otherwise, some users would enter Newark Airport while others entered Liberty International Airport and still others might enter any other combination of these words. The code table is not adding any functionality; it is improving other data entry processes. Occasionally, a code table will have additional columns for auditing purposes. For example, an entry might have the name of the employee who added it as well as the date it was entered.

There are three types of code tables: substitution, static or constant and valid values. The airport abbreviation table described above is an example of a substitution type. Instead of Newark Liberty International Airport, the user can enter EWR. This is a basically a concept. In all probability, the user would have to enter the abbreviation. This would keep the airport names consistent. Allowing the user to enter the actual airport name would result in variations in the names of the same airport. Static or constant code tables often have a single entry in them. A typical example is when a company logo is stored as a file. Sometimes several static pieces of information are maintained in the same code table. Default values are also kept in this type of code tables. For example, the default WordPress role when entering a new user might be Subscriber. This could be placed in a code table to facilitate changes. Valid values would show what values were acceptable for a certain variable. For example, WordPress roles might be Super Admin, Administrator, Editor, Author, Contributor and Subscriber. Check numbers for an application might be from 1000 to 9999.

Code tables are technical in nature. Business files are associated with the problem the application is being developed to solve. For example, WordPress would have a logical file associated with the users that would be involved with a blog. Users have different roles. The roles might be placed in a code table. The need for a user table would be identified from the very beginning of the project. It would be mentioned in the initial user stories. From there, someone would have identified the user file. The different roles might not become apparent until developers started to design files and screens associated with the users. The roles themselves might have been called out in the initial user stories, but the decision to place the roles in a file would probably have been made during development. As long as the roles table conforms to one of the structures discussed above, it is considered a code table. Code tables are sometimes maintained using system utilities like text editors or SQL. Other times, code tables are maintained by screens that were developed for that purpose. In either case, they are still code tables.

Code tables are not counted when counting function points. They should not be. No one knows what code tables may be necessary early in the life cycle. For decades, we have been generating reasonable estimates for new software development using function points as the primary driver of software size. If some of the code tables are identified early, they should still not be counted. The most important reason to identify code tables is to remember not to count them. In addition, if there are maintenance transactions like screens that update the code tables, they are not counted either. This makes sense. Transactions that update code tables are not labor intensive. Even when they are coded, they are the types of transactions that are usually clones from other code table update transactions. Care must be taken to make sure the that none of the code tables have been misclassified. Use the airport code table as an example. If there is an abbreviation and description then it is a code table. If a field is added with the number of runways, then this would indicate that the file had business related information in it. It would stop being a code table and be considered as a logical file.

Code tables are considered when counting Software Non-functional Assessment Process (SNAP) points. These come into play when changes are being made to existing functionality. This is almost always the case with development iterations after the first. The creation of code data is counted like a change to the elementary process that utilizes it. This is unlike the addition of a new logical file (ILF or EIF) which is considered an addition to the functionality of the application. Changes to code data are often counted in a similar manner. Other times code data is considered part of the data that data that is delivering added value to users by data configuration. However, in all cases, code data carries less weight than business data. For most changes, there impact of changing one or more code tables is exactly the same. In addition, no matter how many code tables are involved in a elementary business process, they all count as a single file type referenced (FTR).