When it comes to processes, elementary processes are the lowest level that is considered for estimating purposes. In Adding an Elementary Process the definition of an elementary process was given. It was explained that most elementary processes correspond to one of the function point transactions: External Inputs (EIs), External Outputs (EOs) or External Inquiries (EQs). There is a slight many-to-one mapping. For example, Send a performance report to the employee and Send a performance report to the employee’s manager are two elementary processes. However, they correspond to a single EO if the data and logic for the reports are the same. Adding an Input Screen and Adding an Output Screen are other examples where elementary processes are identified. Elementary processes are sometimes estimated based on the number of file types referenced (FTR) and the number of data element types (DETs).
Typical processes were introduced in Add a Typical Process. It is a way to estimate several elementary processes at one time. They correspond to the typical object maintenance that exists in online applications. For example, adding, editing and deleting posts in WordPress would be a typical process. FTRs and DETs are not not considered. It may seem that a less exact estimate is being generated, but approximations are the very nature of estimating. More precise estimates are not always better.
AS was already stated, the FTRs and DETs are not considered when estimating with typical processes. However, the number of elementary processes are accurate. When using general or macro processes, the number of elementary processes are estimated. The sizes for these groupings of elementary processes are shown in the following tables:
The general and macro process numbers were developed by Roberto Meli. General processes are used when the exact number and type of elementary processes are not known. For example, there may be a process to generate performance reports. These reports have not been specified yet. Therefore, it is impossible to know which reports are EOs and which are EQs. In fact, the exact number of reports has not been determined, but most people think there will be about 12. This could be estimated as a medium size general process and would be estimated as 57.2 function points.
General processes are sometimes assigned by analogy. For example, if you have a process to identify prospects that you have already estimated as a small general process and now you have a process to recruit employees that you think is about the same size, then estimate the recruit employees process as a small general process. Care must be taken when doing this. It is easy to be mistaken when thinking at this high a level. This is especially the case when considering macro processes. Here, the estimating is being done at a very high level. It is easy to make faulty assumptions. Remember that large macro process is probably larger than almost 70% of the new projects that were studied when developing this methodology. 2000 function point projects are larger than 90% of the new projects that were studied. These projects often do not lend themselves to agile development at all. If this size has been reached using these macro estimating techniques, it might be wise to structure a project around doing enough analysis to make sure the sizes are reasonable.
The following chart shows another way to estimate processes that may be composed of several elementary processes:
When one of the above keywords appears in a user story, there is a good chance that the story will be about the size indicated. This is based on an analysis of keywords that appeared in function point counts. They are used by checking user stories to see if any of the keywords are present. If so, then the function point count indicated is a good estimate. If more than one is in the user story, then choose the one with the largest value. Do not add them together. For example, “as a sales manager, I can assign a sales person to a prospect” is a user story which is probably 15 function points. This is based on the word “assign” appearing in the user story. “As a sales manager, I can assign a new sales person to a prospect,” is 25 function points. This is based on the word “new.” It is not 40 function points because both “assign” and “new” are used. Just use the larger one. The two user stories do not seem much different, yet the sizes are. Consider the words to be like tells in a poker game. When the word “new” appears, it seems to mean that the user story is going to be more involved.
This brings up a question regarding epic stories. They are so long that they may involve several of the component keywords. Should they be added? No. Look at epic stories and try to guess how many elementary processes are involved. Estimate it as a general process if that number is between 6 and 20 elementary processes. If it is less than 6, then consider it a typical process or break out the processes separately. If more than 20, consider using a macro process to estimate it.
The use of keywords by function point counters has a long history. When Charismatek released Function Point Workbench, it would assign a function point type when a description was input. For example, if you entered “Assign a sales person to a prospect,” it would be tagged as an External Input (EI). There is a nuance here. My research indicated that “assign” was usually associated with more than one elementary process and would be 15 function points in size. Charismatek felt that if the keyword “assign” showed up in something that was already established to be a single elementary process, then it would be an EI. An average complexity EI is only 4 function points. Both interpretations are valid. For quite some time, Jacqueline Jones taught a class in function point estimating that talked about using certain words as an early indicator of function point size. At an IFPUG sponsored sizing conference, Ton Cagley presented a methodology to use the Charimatek keywords to do function point estimates.