by Fabrizio Di Cola, Nicolantonio Auciello, Domenico Geluardi and Daniele Zottarel

The measurement with standard methods of iterative processes, especially when using agile approaches, is mostly underestimated in its usefulness by many of the agile teams. In the agile context, what we are trying to achieve is a way of estimating the effort that enhances the collaboration of the team, allows certain governance of the project but without any pretension of universality even between projects of the same company in order not to lose "agility" and speed. This is where Story Points are born. Let's see the other side of the coin. In contexts such as those of the Public Company, there are some unavoidable dynamics that require transparency of costs, comparability with certain sectors of the market and "ethics" in the management of the public good lead to a single solution: the use of software measurement metrics even in those sectors of the company that use agile approaches. The need to capitalize the software and at the same time the governance of development cannot ignore the comparability of estimates, in the same company, but also between companies when this governance passes through a comparison of costs with the market. Does all this make it impossible to apply measurement methods together with an Agile approach? If the common goal is to make the company more efficient and not only to use an artificially chosen methodology, absolutely not.

At ISMA 15, we had already illustrated a way to apply function points in an iterative process and in an agile context. Basically, the proposed approach was based on two tracks: the functional dimensioning of an enhancement and a structured way of estimating the velocity of an iteration.

In the example we presented, we consider an enhancement project with a traditional project view (for example an agile backlog) and an iteration view:

We have 6 requirements and divide this project in 4 iterations. We start with the first iteration pushing “Req 1” and “Req 2” in it. We suppose that we are a 1:1 relation Requirement to elementary processes (“Req 1” to EP 1, Req 2 to EP 2 …) and we have 4 modified logical files (Logical File 1 to Logical File 4)

In the iteration 1 we count 20 FP:

• EP 1, an EI, modified, low complexity, 3FP
• EP 2, an EI, modified, low complexity, 3FP
• Logical file 1, an ILF, is modified for the Req 1, 7 FP
• Logical file 2, an ILF, is modified for the Req 2, 7 FP

We have the same value of the enhancement project at this time.

In the iteration 2 we have two requirements (“Req 3” and “Req 4”). We count also 20 FP:

• EP 3, an EI, added for Req 3, low complexity, 3FP
• EP 4, an EI, added for Req 4, low complexity, 3FP
• Logical file 1, an ILF, is modified for the Req 4, so we count 7 FP. The second time this file is modified.
• Logical file 3 added for Req 4, an ILF, 7 FP

This is not the same number of function points added in the enhancement project. The enhancement project would be counted only the first time that logical file 1 is modified:

Then the enhancement project count is 20 FP for the first iteration and 13 FP for the second iteration.

However, after we count the first modification, if the following changes result in a complexity modification, we consider this case counting for the enhancement project the difference from CHGA and CHGB as usual. In the case of an agile context, the change in complexity would lead to an update of the backlog estimation.

In the iteration, to count “velocity” in function point, we count all time a BFC is modified. Iteration 1 is 20 FP and Iteration 2 is 20 FP.

In enhancement project, we count only the first time a BFC is modified. We have to justify the difference.

In case of multiple logical files modification, we have 2 situations:

• “Natural rework”
• “Change request”

In case of an elementary process, this issue is not present. In fact, at the end of iteration all Requirements pushed in it are closed with the necessary level of quality. So, in the iterative process we have not “natural rework” in elementary processes, but we have this situation:

• “Change request”, settled like logical file
• “Bad elicitation” of Requirements
  • It is the case of an Epic we have not decomposed in user stories with the necessary level of granularity. We settled it like the case of a “change request” and used it like an index of poor level of requirements analysis.

We have to analyze the “Natural rework”, the number of function point counted for iterations and the number counted for an Enhancement project

• The modification of the logical file in the enhancement project is a “one-shot” modify. It includes all the small modifications to have the final result.
• The modification of the logical file in the iteration is a “micro modification”. It includes only the subset of modification to achieve the iteration goal.

The difference of function point is justified by the higher productivity of a “micro modification” set than the “one-shot” modification in the enhancement project.

After reviewing the example presented to ISMA, it must now be put into context and applied in reality. When to measure the backlog? When to measure iteration and therefore velocity with a functional measurement?

At least two alternative approaches to solve these questions can be identified. The first approach includes:

• FP backlog measurement
• Measurement of FP iterations
• FP Asset Measurement

This is a scenario in which the example described can be applied at all. The backlog estimation may not be done after each iteration but only, after the initial estimation, when the Product Owner needs to deeply review it. The FP measurement at each iteration allows the continuous alignment of the backlog to the result of the iteration. Finally, just this continuous update of the backlog leads us to minimize the final recount activities and therefore we only have to apply the application count update formula after evolutionary maintenance to update the company assets.

FP counting of each iteration may have a cost to the project and it is certainly necessary that there is experience in Function Point measurement within the agile team. The more widespread this experience is, the less iteration time will be spent on the measurement itself.

A second approach is to reduce the number of counts to just the size of the backlog:

• FP backlog measurement
• Management of the iterative process with agile estimates
• FP Asset Measurement

This approach allows for timely project governance at the beginning and end of the development cycle, as well as the analysis of the impact of changes to the backlog by recounting them when necessary. As an activity that does not follow the normal iterative flow, knowledge of FP measurement is not necessarily part of the team. The measurement expert may be involved in certain phases or in cases of critical changes to make an impact analysis.

However, this makes it impossible to manage velocity in a structured way. The user stories may not initially have the level of detail needed for the measurement (which only those ready to be included in the next iteration will have) and often the level of granularity is not adequate, so that some user stories of the backlog may be broken down into finer-grained user stories in the succession of "Product backlog refining". So, the initial estimates of the backlog could be very rough estimates.

This requires a mixed measurement approach to manage the iterations and the team could use the classical methods of agile process estimation such as story point estimation for iterations. Obviously the backlog will be estimated "twice" (once by the measurement expert with the function points and once by the team with the story points) and somehow this double estimation, although it may lead to an improvement of the agile team's relative estimates for comparison with the "methodological" estimation, could prove to be an extra cost.

The "agile" development is something empirical and pragmatic itself and only with an equally substantial approach can SNAP be dropped effectively in this area.

The measurement effort of SNAP is massive especially when it is compared to the speed required in these highly iterative contexts. Two approaches could be useful for an effective use of SNAP in this context:

• Approach 1 ('Declaratory' (Estimation)): estimation of the impact of SNAP subcategories on the functional measure in terms of impact High, Medium, Low
• Approach 2 ('SNAP measurement'): methodological measurement and use of conversion tables to determine the impact of SNAP subcategories on the functional measurement.

Approach 1 is suitable for velocity estimation. By using approach 2, at the end of the development (after the last iteration), we can make the "SNAP Measure" of the application to capitalize the software.

A company that wants to take a similar approach to the one described will obviously have to meet a number of prerequisites including a mature metrics culture and enough FP and SNAP meters to cover the needs. The choice of which approach to use of those described with Function Points can be the result of many considerations. Surely, if you want to do this, you need to invest in a measurement culture otherwise measurement in Agile contexts will remain just a fantasy.

Measuring iterative processes in software development: apre una nuova finestra F.Di Cola, D Geluardi, D. Zottarel, ISMA 15, May 11th, 2018