Scrum and Function Points: Friend or Foe

This article has about 1600 words and takes about 8 minutes to read.

This article was originally written by Jolijn Onvlee and translated by Xu Dongwei.

How agile are the function points?

Many organizations have realized that they can better manage their software projects by using function points to estimate them. At the same time, there are more and more organizations adopting agile working methods, and they use Scrum more frequently. So here comes the most considerable challenge: Do function points still work in an agile environment, and does Scrum throw them aside? Do function points still present any values in an agile world? In this blog, Jolijn Onvlee and Rini van Solingen show the compatibility of agile and function issues.

Agile/Scrum

More and more organizations are embracing agile (with Scrum as the most common way) to remedy the failing situation of large IT projects. By starting to deliver software directly, customers have direct visibility into the project's progress and can get the value of the delivery every two weeks.

Users no longer have to wait to be available for the highest business value features. In addition, the continuous flow of feedback enables us to deliver in a more practical and usable way. In fact, with Scrum, a large IT project is divided into many smaller projects, making it easier to respond to new ideas and reducing overall project complexity significantly.

Scrum handles system specifications in a completely different way. In Scrum, we use a general term (product to-do list) to describe the product. Then only those parts that offer the highest business value are designed in detail and delivered quickly. The aspects of the remaining work with the highest business value are identified, developed, and delivered. The cycle repeats so that continuous adjustments can be made. This reverses the original expectation that the project would provide pre-defined work. In this case, it would be unreliable to estimate the entire scope of delivery because we would not be able to break down the whole area finely at the very beginning.

Disagreements

The estimation and Budgeting of Scrum are different from the traditional and systematic approach. Traditional approaches are typically quantified by Function Point Analysis (FPA), which estimates software development costs and delivery times. Function Point is a metric used to measure the size of the system. This size estimation is based on the functional specification of the system. To use FPA, one needs to know the details of the system to a certain degree.

Therefore, function points are not well compatible with Scrum. After all, one wants the complete requirements specification in advance. At the same time, the other wants to be able to update the requirements specification at any time and doesn't want to get too specific. The Sprint in Scrum is too short and variable to estimate based on function points. However, in an agile organization, there is also a need to manage costs. "Don't rush, we can know what it costs when the work is done" is unacceptable for most organizations. This means that agile creates anarchy in IT spending, which is unacceptable. The product owner needs to get a clear picture of the output of all work inputs ( targets ) and the final time and money spent ( budget ). This is something that traditional FPA can address.

Similarities

If you study the combination of FPA and Scrum closely, you may realize that they reinforce each other rather than detract from each other. After all, FPA helps us determine the overall scope and appropriate budget, and Scrum helps us achieve the features with the highest business value first but within budget. Therefore, feedback on the system can enter the delivery process as quickly as possible. There are two aspects of feedback: whether the overall scope is correct and whether the whole issue can be addressed within the budget.

This means that the project's to-do list is determined at an integrated level. In Scrum, the product parts with the highest business value usually contain a large amount of detail. This detailed information (preferably in Sprint) is generally sufficient to perform a function point analysis. Then, the results of this analysis can be used to infer the total number of function points for the entire to-do list, which is allowed in the FPA method.

Scrum and FPA are friends

In short, Scrum and FPA can reinforce each other very well. Function points help you manage your total expenses, and with Scrum, you can stay flexible based on new insights. In this respect, the goal of Function Point and Scrum is the same.

Quick wins

Quick wins in the combination of Scrum and Function Point.

The product to-do list describes all unrealized requirements. At the top of the product, the to-do list is the most important entry to the business, and only these entries are available for refinement. The use of FPA allows the scale of the product to-do list to become more specific, as FPA can demonstrate the functionality of what we are trying to do. Thus, FPA summarizes the product to-do list from a functional perspective.

• Objectives are measurable

The detailed product to-do list for the first 6 Sprints is sufficient for FPA estimation (ISO/IEC 24570 Nesma functional scale metric), and the estimated number of useful points can be used to extrapolate the total number of available topics. Therefore, the result can be quantified without needing a detailed specification of the entire product.

• The value of delivery can be measured more easily

The speed at which teams deliver software is measured in story points, which are a relative estimate of the size of the work. We should never confuse story points with function points. They are not the same (although the names are pretty similar). Function points account for the entire project， but story points keep Scrum teams from getting overfull. However, in Scrum, it's hard to articulate the value of delivery, and that's what function points excel at.

• Prioritization of functions is accelerated

An important aspect of Scrum is identifying the highest business value features so that the next Sprint works from those features. It becomes easy to measure the entire wish list (and the next few Sprints in this wish list) based on the estimated FPA, and this approach can also be used for feature grouping. Then we can document the overall picture, and all changes are traceable.

• Assistance with estimation

Estimation is a team task. Scrum uses story points for estimation, but these are relative estimates: teams can use story points to compare themselves, but not to compare with other groups. Function points, however, are total estimates that can be compared to other teams. Function points can be compared across projects, not only in advance but also during and after the project is completed. Therefore, teams get additional help from function points in their estimation.

• Visible improvement

Because FPA provides an objective metric, we can highlight the status of improvements with the Assistance of function points in a Scrum retrospective. So you can thus help the team learn from each other and identify the main factors hindering progress.

• Identifying the business case for Scrum

While many organizations are enthusiastic about Scrum, we hear through the grapevine that the Scrum process has resulted in more rework (as users come up with new ideas and changes the software frequently), making the Scrum process more costly. By measuring the number of feature points added, we can have a good study of the productivity of the process and the ongoing adjustments. This allows for an objective and accurate calculation of the business case.

This blog was initially published as a review article on AutomatiseringGids (published in Dutch).

---

About the Authors

Jolijn Onvlee (Jolijn@Onvlee.com) is an independent FPA expert, consultant, auditor, and lecturer in quality, budget, and productivity management. Jolijn also served as chairman and director of Nesma for many years.

Rini van Solingen is the CTO of Prowareness (Rini@scrum.nl) and a professor at the Delft University of Technology. Rini is the author of the book "The Power of Scrum", translated and published in French, German and English.

About the Translator

Xu Dongwei, a senior enterprise agile coach, has experience in foreign enterprises, state-owned enterprises, private enterprises, software engineer, traditional large project manager, agile coach and consultant, he started to practice agile in 2008 and is very fascinated by agile, lean, SAFe, DevOps, etc. He hopes He can contribute to the development of Chinese enterprises and make a lot of like-minded partners at the same time.