How agile are Function Points?

Many organizations have learned that they can get a better grip on their software projects by estimating them with function points. At the same time, we see that more and more organizations have an Agile way of working, usually by applying Scrum. The big question is whether Function Points remain standing. Does Scrum throw them overboard? Or do Function Points still have value in an Agile world? In this blog Jolijn Onvlee and Rini van Solingen show which frictions and similarities there are.

Agile/Scrum

Agile (with Scrum as the most used approach) is embraced by a growing number of organizations as the solution to the failure of large IT projects. By starting to deliver software directly, every two weeks a customer receives direct insight into the progress and added value. Users no longer have to wait for the functionality with the highest business value. In addition, the continuous flow of feedback leads to valuable systems that work, much faster. In fact, with the use of Scrum, a major IT project is cut into many small projects. This makes it easier to respond to new insights and reduces the complexity of the whole project enormously.

Scrum handles system specifications in a drastically different way. The product is described only in general terms (called the Product Backlog).Then, at first only those parts are worked out in detail that have the highest business value and theses are delivered quickly. After this delivery the highest business value is determined again, developed and delivered, and so on. Constant adjustment is possible in this way. This supersedes the original idea of a project that delivers a predefined outcome. The estimate of the entire delivery scope no longer makes sense, simply because the entire scope is no longer worked out in detail. The spot on the horizon can shift at any time.

Friction

Scrum handles estimating and budgeting differently from a more traditional and systematic approach. The traditional approach often uses Function Point Analysis (FPA) for quantification. FPA is used to estimate how much making the software is going to cost and how long it takes to deliver this. A function point is used as a metric to determine the size of the system. This sizing is done on the basis of the functional specifications. A certain degree of detail of what you’re going to make is necessary for FPA.

So it seems that Function Points and Scrum do not fit together. After all, the first one wants a complete specification in advance and the other one wants to question and update the specification at any time and does not go too far into detail. The sprints within the Scrum approach are too short and too varied to estimate based on function points. At the same time, also within the Agile organizations, there is a need to control the costs. ‘We’ll see at the end how much it has cost’ is unacceptable for most organizations. That would mean that Agile creates anarchy in IT spending, which is nonsense. Even with Scrum a customer has a need for control. The product owner wants to maintain an overview of the results of all these efforts (goal) and how much time and money it has cost in the end (budget). And that is precisely where traditional FPA offers a solution.

Similarities

If you look into detail at the combination of FPA and Scrum, you see that they reinforce rather than weaken each other. After all, FPA helps in establishing the overall scope (the spot on the horizon) and the appropriate budget. Scrum helps to realize the functions with the highest business value within that budget first. As soon as possible feedback is fed into the delivery process. Feedback on two fronts: first, whether the overall scope is correct and, secondly, whether the entire problem can be solved within budget.

In practice this means that the backlog for the project is determined at a global level. Within Scrum it is common practice that the part of the product with the highest business value already has a significant amount of detail. This level of detail (preferably for a number of sprints) is usually sufficient to do a function point analysis. You can then use that analysis to determine the total number of function points for the entire backlog by extrapolating. Within the FPA method, this will be allowed.

Scrum and FPA are friends

In short, Scrum and FPA can help and strengthen each other excellently. The function points help you keep a grip on the total expenses. By using Scrum you remain flexible based on insights. Ultimately it is for you to solve the overall problem. As fast, as good and as cheap as possible. In that area, function points and Scrum have a common goal.
So Scrum and FPA are friends. Loss of control and exceeding the budget is the (common) enemy!

Quick wins

Quick wins in the combination Scrum and Function Points

  1. Faster concretization of the Product Backlog
    The Product Backlog is the description of all the unimplemented requirements that have to be made. At the top of the Product Backlog are the items that are most important to the business and only those items are worked out in detail. The size of the Product Backlog can be made concrete by using FPA. FPA shows what functionality is required. FPA thereby provides a summary of the Product Backlog in functional terms.
  2. Measurable goal
    A detailed Product Backlog for the first six sprints is enough to make an Estimated FPA (ISO/IEC 24570 Nesma functional size measurement method). The number of function points can then be extrapolated to the total. Thus, the ultimate goal (the spot on the horizon) can be quantified, and the final result is made tangible, without the need for detailed specifications for the whole product.
  3. Easier measurement of ‘added value’
    The speed at which a team delivers software is measured in story points. These are relative estimates of the size of the work. These story points should not be confused with function points. They don’t even look like each other (except in name, of course). Function points are facing outward and consider the overall project. Story Points are facing inward and help prevent a Scrum team to bite more than they can chew. In Scrum however, it is difficult to express the value delivered. However, this can excellently be done in terms of: Function Points!
  4. Help with prioritizing functionality
    An important aspect of Scrum is to determine the desired functionality with the highest business value, which is then going to be picked up in the next sprint. With the Estimated FPA the total wishlist – and within that, the next sprints – can be measured in a simple way, also with regard to the grouping of functionality. The overall picture is kept and shifts are traceable.
  5. Assistance in making estimates
    Estimating is the task of the team. To make an estimate always is (and remains) a tricky business. After all, a team does not have a crystal ball and before you know, estimates are used as if it were guarantees. Scrum estimates with story points, but these are relatively: comparable to the team but not beyond. Function Points, however, are absolutely and comparable. Function points are comparable between projects and cannot only be measured in advance, but also during and after a project. Thus, the team gets an extra help in making estimates.
  6. Detecting improvements
    Because FPA provides an objective measure it can be used in the retrospective of the Scrum process to show improvement. So you can help the teams to learn from each other and to detect the main inhibiting factors.
  7. Confirming business case for Scrum
    While many organizations are enthusiastic about Scrum, roumours can be heard through the grapevine that Scrum processes include more rework (by advancing insight) which will make them more expensive. The number of function points of the new and enhanced functionality can be determined and thus the productivity of both the adaptation and the entire process can be established. Then the business case can be objectively determined.

This blog has been originally posted as an opinion article in AutomatiseringGids (in Dutch).

 

About the authors

Jolijn Onvlee (jolijn@onvlee.com) is an independent FPA specialist and consultant, auditor and lecturer in the field of quality, budget and productivity management. Jolijn has also worked for many years as chairman and board member of Nesma.

Rini van Solingen is CTO at Prowareness (rini@scrum.nl) and professor at the Technical University of Delft. Rini is the author of the book “The Power of Scrum”; now also published in French, German and English.

Share this post on:

4 Comments

Leave a Comment
  1. Ian Alyss says:

    Hi Jolijn and Rini,

    Nice article, but still there is a lot of resistance within the developers community against the use of function points. There’s a nice article from Jean-Pierre Fayolle that explains this: http://qualilogy.com/en/do-developers-dream-of-automated-function-points-1/ How do you think about this.

    Ian

  2. Hi Ian, yes I recognize the resistance with developers when FPA is introduced in the organization. They are afraid that their (individual) productivity will be measured and hold against other developers. But…. FPA cannot be used for measuring the productivity of an individual. It is allways the team-effort you are measuring. FPA is a tool for the product owner! And there are several ways to implement FPA in your srum project!
    I challenge that FPA is a very difficult method, especially the Estimated FPA as mentioned in the blog.

Leave a Reply