Many applications request information on screens. The example above is the WordPress screen that an administrator would use to add a new user. If we were developing the WordPress application, then adding this screen would probably be in the first release. It might be changed in future releases.
The initial user story for this might be: “As an administrator, I can add a new user to the site.” Details of the screen may be supplied through conversations with the users. It is possible that there will be another initial user story that says, “As an administrator, I can add a new subscriber to the site.” In fact, I could have stories for contributors, authors, editors and administrators. This is where a decision must be made. Will the same information be added for each user role, or will the each role of user require different information to be added. If they are basically the same, then there is only one screen to estimate. If they are significantly different, then each screen should be estimated separately. Of course, words like “basically” and “significantly” are weasel words. (The word “significance” means something to a statistician, but for most of us, it is a weasel word.) Here is one of the many places where an estimator must use his or her judgement. When two screens are 90% the same, they are the same. Another hint in this particular case is that the screen says Add New User. When I enumerate my logical files, I will probably have a single file for users, not one for each role.
WordPress runs in a web browser. This is a technical decision. It is not considered in the estimate for adding the screen. None of the functionality that the web browser delivers is considered in the estimate. Why should it be? We are not developing the browser. Furthermore, we might need an estimate before we knew how we were implementing the screen. We might have developed WordPress as a stand alone Windows application. We might have written our initial user stories before that decision had been made. Something similar can be said of the Windows operating system. Its functionality is not estimated as part of our development estimate. If a window must be scrolled in order to see the entire output, this is part of the Windows functionality and is not factored into an estimate of the output screen.
On the left side of the screen is a menu. Many applications have their menus at the top of the screen. In any case, the menus are not estimated separately. An administrator needs to be able to input users. Something must trigger the Add New User screen to be presented. That is essentially part of the input screen. It is not estimated separately. This is consistent with the way that user stories are usually written. We would not expect to see a story like “As an administrator, I must click on a menu item to present the Add New User screen” in addition to the stories already mentioned.
Once you have decided that there is a single input screen, that screen corresponds to an External Input (EI). There are a few ways to proceed. Roberto Meli has analyzed a corpus of function point counts and determined that the most likely function point size associated with an EI is 4.2 function points. This could be used as an estimate.
A different corpus of function point counts was subject to keyword analysis. The following slide shows the result for input transactions. When a user story contains one of these keywords, there is a good chance that it is an EI that is the indicated number of function points in size. Use this as your estimate unless you have reason to believe otherwise.
The number of function points for an input can be derived based upon the number of File Types Referenced (FTRs) and Data Element Types (DETs). FTRs is the number of logical files that are being written to by the input. It also includes any files that are read from to but not written to in order to process the input. Part of the estimating process is to maintain a list of these logical files. Looking at the screen above, it is probable that there is 1 FTR for Users.
DETs are basically the fields that are requested on the screen. There is one extra field called the action code. Even if it is not visible, it is assumed to be there. Thus, there is always at least 1 DET on an input screen. There is also a DET if the screen might generate an error message. For example, if there were a field that requested a date and the user entered an invalid date, then an error message would be generated. This would be counted as a DET. If the screen generated error messages for invalid dates, invalid amounts and other invalid input, the error messages would still be considered a single DET. Each of the fields requested, as well as any that may be displayed, are possible DETs. Each DET must be unique. For example, if you were inputting a value for each month, then you would have one DET for that value, not 12. There can be some questionable cases. In the screen above, there are separate fields for the first name and the last name. Is this one DET or two? I would choose two. Be careful of too much consolidating or there might only be a few DETs: one for numbers, one for character strings and one for dates. This is clearly too much consolidation and would lead to bad estimates. Based on these rules, the above screen has 10 DETs: action code, username, email, first name, last name, website, password, send user notification indicator, role and a DET for a possible error message. In all probability, the screen would return an error message if the user entered a username that was already in use.
EI screens are between 3 and 6 function points. The matrix below show the how the function points are assigned. Note that the diagonal from the lower left to the upper right have the same values and they correspond to an average input. The cells on the upper left correspond to lower sized transactions, while those on the lower right correspond to higher size. In our example screen above, an EI with 1 FTRs and 10 DETs would have a function point size of 3. Remember that Roberto Meli would have estimated 4.2 function points without even counting FTRs or DETs.
It is important for estimators not to become obsessed with exact numbers for DETs and FTRs. First, it does not matter whether your DET count is any number between 5 and 15, your estimate will come out the same. In our discussion above, we questioned whether our DET count should have been 9 or 10. Either decision would yield the same estimate. When you have a FTR of 1, any DET count less than or equal to 15 will yield the same number of function points. If you are estimating schedule and effort, you are going to look at many transactions. You will then have to estimate the values for over a dozen cost drivers. If you are a product owner, you will also have to identify the most important stories to implement in the next iteration. You will be involved in other activities such as communicating with the user community. You just do not have time to obsess over DET and FTR values. Guess a little!
This shows how the above screen would have been estimated. But how does this compare to the original user story, “As an administrator, I can add a new user to the site.” A user story like this would be an EI with 1 FTR and 2 DETs. The EI matrix indicates that this would be 3 function points. If we had depended on the keyword analysis, the estimate would have been 4 function points. According to Roberto Meli, the average EI is 4.2 function points. This may seem like a big difference, but it tends to average out over the entire application. In other words, some of the stories will be smaller than estimated, but some will be larger.