How to Count Function Points from User Stories

I was recently involved in a consulting engagement where Agile methodologies were being implemented with User Stories as the documentation standard. The organization had used function points (FPs) for years on their waterfall projects and were wondering if they could use them for their Agile methodology – and if User Stories would be a good input into the FP counting process. The answer I provided was a resounding “YES.” Having User Stories is actually a huge advantage to counting FPs, especially early in the lifecycle, because User Stories are typically focused on the user perspective, just like FPs.

The only difficulty in using FPs in Agile methodologies is determining what to count and when to count. As with any metric, this always goes back to the purpose. For example, if you want to know the size of the final delivered product, then you count the FPs at the end of the project. If you want to estimate effort for a Sprint or Program Increment (PI), then you need to count at the beginning of the Sprint or PI.  The key is defining the purpose early in order to have access to what you need at the time of data collection.

When actually counting FPs from User Stories, there are a few tips that help with the process. Depending on the level of the User Stories, more questions or assumptions may be needed to get to an accurate FP count. There are also key words used in User Stories that may help identify FP components (e.g. Maintain, Report, Enter, Select). Often User Stories equate to transactional functions in FPs, so it is important for the FP analyst to identify data functions as they go along.

More tips and advice, including real-life examples, will be provided in my upcoming webinar, “Counting Function Points from User Stories,” taking place on Wednesday September 28, 2016 at 12:00 pm EST. Please register here. If you have any questions before the webinar, just leave a comment and I’ll be sure to address them during the presentation.

Lori Limbacher
Estimation Specialist; Certified Function Point Specialist (CFPS)

Written by Lori Limbacher at 05:00
Categories :

Function Points in the Philippines?

David LambertI know what you are thinking – and I was thinking the same thing. Is there really a company using function points in the Philippines? Yes, there is. In fact, I recently traveled to the Philippines to train a lean development team on the use of function points as a measure for their metrics program.

I’d never been to the Philippines before, so it was an interesting experience to be in a new place, but it was also interesting to see how function points are being used around the world.

This particular team is way above the curve as far as their processes and documentation is concerned. They were looking for a standardized process to size their change requests in order to measure productivity and quality and help forecast future projects. Their intent is to start sizing those small change requests and establish some benchmarks for their applications. Once those benchmarks are in place and they have gathered some valuable data, the team intends to start using the data to help size their larger projects. The sizing for those projects will allow them to better manage staffing, cost, and quality related to those projects.

This, of course, is something we encourage and espouse as a best practice for development teams. So, it was great to see that this mentality has really taken hold in this organization, and that they truly understand the benefits of sizing.

I also learned while I was there that several larger technology companies are starting to use the Philippines as a source to locate their infrastructure and development teams. So you may not think of the Philippines when it comes to the IT domain, but the country is starting to make some strides towards closing the gap on the rest of IT world. I know for sure that one lean development team has closed the gap and function points have allowed them to standardize their process even further.

I look forward to seeing how the use of function points continues to develop in the country – and beyond. Is your organization using function points? If not, it’s time to catch up!

 

David Lambert
Managing Consultant

Written by David Lambert at 05:00

The Origins of Function Point Measures

Trusted Advisor

Note of Thanks

We’re pleased to share this month’s Trusted Advisor, which was written by Capers Jones. Capers is a well-known author and speaker on topics related to software estimation. He is the co-founder, Vice President, and Chief Technology Officer of Namcook Analytics LLC, which builds patent-pending advanced risk, quality, and cost estimation tools. Many thanks to Capers for participating in Trusted Advisor and allowing us to publish his report!

Scope of Report

The 30th anniversary of the International Function Point User’s Group (IFPUG) is approaching. As such, this report addresses a brief history of the origin of function points. The author, Capers Jones, was working at IBM in the 1960’s and 1970’s, observing the origins of several IBM technologies, such as inspections, parametric estimation tools, and function point metrics. This report discusses the origins and evolution of function point metrics.

Introduction

In the 1960’s and 1970’s IBM was developing new programming languages, such as APL, PL/I, PL/S etc. IBM executives wanted to attract customers to these new languages by showing clients higher productivity rates. As it happens, the compilers for various languages were identical in scope and had the same features. Some older compilers were coded in assembly language, while newer compilers were coded in PL/S, which was a new IBM language for systems software. When we measured productivity of assembly-language compilers versus PL/S compilers using “lines of code (LOC),” we found that even though PL/S took less effort, LOC per month favored assembly language. This problem is easiest to see when comparing products that are almost identical but merely coded in different languages. Compilers, of course, are very similar. Other products, besides compilers, that are close enough in feature sets to have their productivity negatively impacted by LOC metrics are PBX switches, ATM banking controls, insurance claims handling, and sorts.

A Better Metric

To show the value of higher-level languages, the first IBM approach was to convert high-level languages into “equivalent assembly language.” In other words, we measured productivity against a synthetic size based on assembly language instead of against true LOC size in the actual higher level languages. This method was used by IBM from around 1968 through 1972.

An IBM Vice President, Ted Climis, said that IBM was investing a lot of money into new and better programming languages. Neither he nor clients could understand why we had to use the old assembly language as the metric to show productivity gains for new languages. This was counter-productive to the IBM strategy of moving customers to better programming languages. He wanted a better metric that was language independent and could be used to show the value of all IBM high-level languages. This led to the IBM investment in function point metrics and to the creation of a function-point development team under Al Albrecht at IBM White Plains. 

The Origin of Function Points

Function point metrics were developed by the IBM team by around 1975 and used internally and successfully. In 1978, IBM placed function point metrics in the public domain and announced them via a technical paper given by Al Albrecht at a joint IBM/SHARE/Guide conference in Monterey, California. Table 1 shows the underlying reason for the IBM function point invention based on the early comparison of assembly language and PL/S for IBM compilers. Table 1 shows productivity in four separate flavors:

1. Actual lines of code in the true languages.
2. Productivity based on “equivalent assembly code.”
3. Productivity based on “function points per month.”
4. Productivity based on “work hours per function point.”

Function Point Evolution

The creation and evolution of function point metrics was based on a need to show IBM clients the value of IBM’s emerging family of high-level programming languages, such as PL/I, APL, and others. This is still a valuable use of function points, since there are more than 2,500 programming languages in 2016 and new languages are being created at a rate of more than one per month.

Another advantage of function point metrics vis a vis LOC metrics is that function points can measure the productivity of non-coding tasks, such as creation of requirements and design documents. In fact, function points can measure all software activities, while LOC can only measure coding.

Up until the explosion of higher-level programming languages occurred, assembly language was the only language used for systems software (the author programmed in assembly for several years when starting out as a young programmer).

With only one programming language, LOC metrics worked reasonably well. It was only when higher-level programming languages appeared that the LOC problems became apparent. It was soon realized that the essential problem with the LOC metric is really nothing more than a basic issue of manufacturing economics that had been understood by other industries for over 200 years.

This is a fundamental law of manufacturing economics: “When a manufacturing process has a high percentage of fixed costs and there is a decline in the number of units produced, the cost per unit will go up.”

The software non-coding work of requirements, design, and documentation acts like fixed costs. When there is a move from a low-level language, such as assembly, to a higher-level language, such as PL/S, the cost-per-unit will go up, assuming that LOC is the “unit” selected for measuring the product. This is because of the fixed costs of the non-code work and the reduction of code “units” for higher-level programming languages.

Function point metrics are not based on code at all, but are an abstract metric that defines the essence of the features that the software provides to users. This means that applications with the same feature sets will be the same size in terms of function points no matter what languages they are coded in. Productivity and quality can go up and down, of course, but they change in response to team skills.

The Expansion of Function Points

Function points were released by IBM in 1978 and other companies began to use them, and soon the International Function Point User’s Group (IFPUG) was formed in Canada.

Today, in 2016, there are hundreds of thousands of function point users and hundreds of thousands of benchmarks based on function points. There are also several other varieties of function points, such as COSMIC, FISMA, NESMA, etc.

Overall, function points have proven to be a successful metric and are now widely used for productivity studies, quality studies, and economic analysis of software trends. Function point metrics are supported by parametric estimation tools and also by benchmark studies. There are several flavors of automatic function point tools. There are function point associations in most industrialized countries. There are also ISO standards for functional size measurement.

(There was never an ISO standard for code counting, and counting methods vary widely from company to company and project to project. In a benchmark study performed for a “LOC” shop, we found four sets of counting rules for LOC that varied by over 500%).

Table 2 shows countries with increasing function point usage circa 2016, and it also shows the countries where function point metrics are now required for government software projects.

Expanding Use of Function Points

Several other countries will probably also mandate function points for government software contracts by 2017. Eventually most countries will do this. In retrospect, function point metrics have proven to be a powerful tool for software economic and quality analysis.

Trusted Advisor Guest Author

Again, our sincere thanks are extended to our guest author, Capers Jones.

You can download this report here

Written by Default at 05:00

Can Function Points Be Counted/Estimated From User Stories?

Trusted Advisor

Introduction

Since the invention of function points (FPs) any time new development methods, techniques, or technologies are introduced the following questions always arise:

  • Can we still use FPs?
  • Do FPs apply?
  • How do we approach FP counting?

These questions came up around middleware, real-time systems, web applications, component-based
development, and object-oriented development, to name a few. With the increased use of Agile methodologies, and therefore the increased use of User Stories, these questions are being asked again.  It is good to ask these questions and have conversations to ensure that the use and application of FPs is consistent throughout the industry in all situations.  The short answers to the questions are:

  • Can we still use FPs? YES. 
  • Do FPs apply? YES. 
  • How do we approach FP counting? The answer to this last question is what this article will address.

Getting Started – Determine the Purpose and Scope

As with any FP count, it is important to identify the purpose of the count and to fully understand how the resulting data will be used.  This will ensure that the correct timing, scope, and approach is used for the FP count.  The following are examples of situations where FPs can be useful.

Purpose: High-level estimate to determine feasibility

If the purpose is to determine the feasibility of moving forward with the project or to complete a proposal, then typically a high-level estimate in a range is adequate. For this count the timing would be "now," and the scope would be whatever functionality is going to be developed. At this point in the life cycle not all information may be available, so some assumptions may need to be made. It is important to document these assumptions so that if the project progresses differently than planned it can be explained. For example, a User Story may state that "As a User I want to have a Dashboard showing application statistics."  It may be too soon to know the exact details, so an assumption of five average complexity External Outputs (EOs) may need to be made.  

Purpose: Estimate for Project Planning

Once a detailed plan is required, then more detailed estimates for effort and cost are necessary. For this purpose, the FP sizing should be completed at the start of the life cycle and updated at each major development stage. For Waterfall it could be at Requirements, Logical Design, and Physical Design phases. For Agile, the timing could be at Program Increment (PI) planning, or Sprint planning or both.  This purpose will require more accurate and thorough data, which requires a more detailed FP count, so more detailed User Stories are typically available. For example, the above Dashboard User Story may be broken down into 5 separate User Stories each describing a specific report: "As a User I want to be able to see a pie chart showing customer complaints by type."  In this case, each report can be examined to determine uniqueness and counted accordingly.

Purpose: Manage Change of Scope

Once a project is underway it is a good idea to track changes in scope to determine if the effort, cost, and schedule are going to be impacted by the change. These types of counts can be completed at different phases or at the time the scope change is identified. Once a change is sized using FPs, estimates can be developed to determine if the change should be incorporated into the current project and/or Sprint, or moved to another project and/or Sprint. A new User Story could be "As a User I want to be able to search customer complaints by type." In this case, a new report would be identified. If the User Story was "As a User, I want to be able to choose the color of customer complaint types in the pie chart;" this would be a change to the initial report we counted.

Purpose: Measure Quality and Productivity

If the purpose of the FP count is to support measuring the actual quality and productivity achieved for a project, PI, or Sprint, then typically User Stories wouldn’t be the source document of choice. This type of count is completed once functionality has been delivered, so ideally one would want to use the "live" system or user manuals to identify the actual functionality delivered to obtain the most accurate measurement. However, if access to the system isn’t available, User Stories may be the only source documentation available. Often documentation isn’t updated after the fact to show changes of what was and what wasn’t implemented so for this purpose it is important to confirm with development staff and/or users what was actually delivered along with referencing the User Stories. 

Utilizing User Stories for FP Counting – Overall Approach

Once the purpose and scope have been determined, the actual FP counting can begin. Applying the International Function Point User Group (IFPUG) rules is the same regardless of the purpose; however, the level of detail and the inclusion of functionality may be different depending on how the data will be used.

Conducting FP counts from User Stories is a bit easier than from other documentation since the majority of User Stories focus on the User perspective of "what" functionality is desired and not on "how" the functionality will be developed and delivered. Sometimes this perspective is difficult to find when looking at Designs or even the flow of physical screens. User Stories by their nature keep the FP analyst seeing things from the User perspective.

The IFPUG counting process starts with defining scope and boundaries and then moves on to identifying data functions and transaction functions. With a list of User Stories, it is more likely that all of this will be decided together as the count develops.

When counting from User Stories, the best approach is to just start walking through them one by one.  Oftentimes User Stories are grouped by categories (e.g. Order Entry, Validations, Reporting, Financials, etc.). If that is the case, it is best to focus on one category at a time. If it is early in the life cycle and the application boundaries are uncertain, it is best to take a first cut at counting the functions. Once the full scope of functionality is known boundaries can be determined and the FP count can be adjusted as necessary.

In following the IFPUG rules, it is important to count the logical functions. This can be difficult depending on the level of User Stories. It would be wonderful if everyone followed the same format and wrote User Stories the same way, but unfortunately that is not the case. One organization may have one high-level User Story for a project, while another organization may write multiple User Stories for the same functionality. One of the benefits of using FPs for sizing is that the method is consistent across all methodologies and isn’t impacted by how the documentation is completed. For example:

High Level – One User Story

  • As a User, I want to be able to enter, update, delete and view orders in the system to avoid manual paperwork.

Lower Level – Multiple User Stories

  • As a User, I want to be able to enter new orders in the system to stop paperwork.
  • As a User, I want to be able to edit orders previously entered in the system to stop paperwork.
  • As a User, I want to be able to delete orders previously entered to avoid incorrect orders be processed.
  • As a User, I want to be able to enter selection criteria to view orders previously entered in the system to stop searching paperwork.
  • As a User, I want the system to use entered selection criteria to display the correct orders to stop searching paperwork.
  • As a User, I want the system to validate the data entered into the fields when an order is added or updated to ensure accurate data is entered.
  • As a User, I want the system to validate the ordered product is "on hand" before accepting the order.

In the above examples, the FP count would be the same. When a User Story seems to be at a high level, it is important to break it down into all of the Elementary Processes (EP). When User Stories are written at a lower level, it is important to look at all of the similar stories together to potentially combine them into the EPs.

The result of the example above is as follows:

User Stories and Function Points

User Stories typically equate to the Transactional Functions (EIs, EOs, EQs); however, it is important for the FP Analyst to also keep Data Functions in mind while analyzing the User Stories. There may not be a list of tables or a data model available, so the FP Analyst may have to assume the ILFs based on the transaction functions.

If early in the life cycle assumptions may need to be made as documented above. Since the User Stories imply the project is automating a manual system then all functions would be new. That would mean that in order to edit or display orders previously entered, they would need to be stored somewhere; hence counting the ILF. 

If at all possible, the FP Analyst should meet with Subject Matter Experts (SMEs) who understand the User Stories to get a full understanding and/or answer any questions. In addition, the FP Analyst should reference existing systems that may be comparable or past counts that may be relevant. FP Analysts usually have knowledge of many types of systems. It is okay to bring that knowledge and experience to the FP count to help identify potential functionality. Of course, everything still should be validated by the SMEs. 

If SME involvement is not possible, or if things are still not clear, then any assumptions that are made need to be documented fully. This will ensure that the FP count can be explained and updated correctly as the project progresses. In the example above, the assumptions document how the complexity was determined (e.g. Product file used for validation on Create and Edit EIs; Data Element Type (DET) assumptions). In addition, any further questions are documented (e.g. Need to check for multiple order Types that could impact the Record Element Types (RETs) and thus functional complexity of the ILF – this may also impact the number of Transactional functions).

Agile Development - Additional FP Counting Considerations

Since User Stories are typically associated with Agile development, it is worth mentioning a few items to consider for the FP counting in terms of timing and inclusion.

FP counting can be completed at the Program Increment (PI) level and/or the Sprint level. The PI usually encompasses the final delivered functionality, so the FP counting is completed normally. For an estimate, the count can be completed at PI planning. For quality and productivity measures, the counting occurs at delivery of the PI. Counting Sprints is handled a little differently.

Sprints can also be counted for estimation/planning and at the end of the Sprint for productivity and quality measures.  However, the sum of the Sprints is often greater than the PI count. The level
at which the User Stories are written can be impacted by the time boxing of the Sprints. For example, an initial User Story may be, "As a User, I want to be able to create a new order." During Sprint planning, it may be determined that the entire function cannot be completed in one Sprint, so it may be changed to two User Stories:

  • As a User, I want to be able to enter general information when creating an order.
  • As a User, I want to be able to enter order details when creating an order.

In this case, the FP count of the Transaction would be as follows:

FP count of user stories

The Sprints cannot be added together to obtain the total FP count for the project. Counting at the Sprint level is usually for internal measures to ensure the PI goals will be attained. It can also point out inefficiencies in the development process. If too much "rework" is occurring, perhaps changes need to made in how the project is being planned and managed. The ultimate goal would be to complete an entire EP in one Sprint and only have to revisit it in a later Sprint if new requirements are discovered.

Conclusion

FPs are the best measure for "size" and can be used for all methodologies and technologies. FPs can be counted from any documentation or from just interviewing SMEs. The most efficient and accurate FP counting uses both supporting documentation and information from SMEs. User Stories are an excellent source of information for FP counting. User Stories represent the User perspective and are typically written in a way that describes the functionality required. So, “Can function points be counted/estimated from user stories?” Absolutely. “What level of granularity is required?” Any level can be used; however, as with any documentation used, the more detailed the User Story the more accurate the FP count.

Written by Default at 05:00
Categories :

A Customized Sizing Model

We work with a lot of clients, and they vary in size, industry, and location. They also, of course, vary in the reason they come to us for help. Sometimes they're in need of training, sometimes they're looking for help in one specific area, and sometimes they need help identifying what their actual problem even is. The common theme between all of our engagements is that our focus is on value: What value can we provide to our clients that will truly impact their organization, beyond even IT?

In a recent engagement, a business came to us with a problem. They were bidding on a Navy contract. The contract required the use of function points. Their experience with sizing was minimal. Could we help?

Yes.

But, we believed that the company needed more than just one simple size for the entire project. The value we provided was in leveraging our experience to build a customized, flexible sizing model to most effectively meet the needs of the client - and for less than the cost of our competitors.

Read the case study to find out more about the engagement.

Download.

 

 

 

Written by Default at 05:00

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!