“Functional metrics remain key in the age of AI” A conversation with Luigi Buglione

On May 16, during the 1st Metrics Event organized by GUFPI-ISMA in Rome—an event we had the pleasure of sponsoring—we sat down with one of the world’s leading experts in software measurement: Luigi Buglione. President of GUFPI-ISMA, Secretary of IFPUG, Academic Director and Vice President of ISBSG, Luigi has dedicated his career to promoting standards such as IFPUG Function Points and SNAP to improve estimation, productivity, and data-driven decision-making.

In this interview, we discussed the role of artificial intelligence in software development and estimation, the current state of Agile, the importance of measuring to improve, and how to approach the future from a quantitative and human perspective.

Interview made by Julián Gómez (CDAIO in LedaMC and Quanter). In Italian, subtitles available in English and Spanish.

Julián Gómez: First of all, thank you Luigi for accepting this interview. I think it will be very interesting because you’re a reference in the world of metrics.
Your opinion is always valuable to understand where this field is headed.

Luigi Buglione: Thank you, Julián. Thanks to Quanter Smart AI Estimation.

JG: OK, thanks. To begin, H.P. Lovecraft once said: “That is not dead which can eternal lie, and with strange aeons even death may die.”
Has Agile died, or does it still have something to offer?

LB: It definitely still has a lot of value to offer. What we need is to improve our skills, especially when it comes to measuring sprints and interactions.

We have to stop estimating based only on experience, using story points or t-shirt sizing, and start introducing functional and non-functional measurement, but with quantitative metrics.

Using Function Points, SNAP Points, or other ISO-compliant non-functional metrics can certainly help.

Without that, estimates in person-days remain highly variable.

JG: Right. Since we’re talking about leveraging Function Points and SNAP Points—recently, IFPUG, in collaboration with Quanter, published a report on the software development market, highlighting the benefits of these metrics even in Agile contexts. What benefits would you say companies are missing out on if they haven’t adopted product-based metrics yet?

LB: Mainly two things:

• They can’t quantify the value of an asset (what isn’t measured doesn’t exist, only time worked does).
• And more importantly, from the standpoint of organizations like ISBSG, there’s the issue of productivity.

If you don’t have a size divided by time worked, you can’t calculate productivity. You’re left with effort measured in story points or based on subjective estimates.
And without historical data, you start from scratch every time. In Italian, we say it’s like having the memory of a goldfish.

JG: Exactly. You’ve spoken in the past about the concept of fact-based decision-making, which fits perfectly with the software development paradigm. What common mistakes do you see in organizations when they try to make decisions based on data?

LB: That they don’t collect data. Particularly project managers, who should have studied this in guides like PMBOK, where the first thing you do in a project closing phase is collect data.

In Agile, this would be a retrospective.

The problem is that it often doesn’t happen—people say there’s no time for it. Which really means it wasn’t planned.

So that’s often the first area for improvement.

JG: Thank you, Luigi. Given your experience in organizations like GUFPI-ISMA, IFPUG, and ISBSG, what do you think is needed to overcome the resistance some companies have toward adopting ISO/IEEE standards like Function Points or SNAP?

LB: The key is understanding the mindset of those who say “I don’t need them” or “They’re useless”.

In my experience, many such people are managers who don’t want to dive deep and focus only on short-term profitability.

But if you start to realize that you can’t say how long something will take without first knowing how big it is, and that you need an objective measure with very low subjectivity, then any number becomes significant.

It’s like in The Hitchhiker’s Guide to the Galaxy, where the magic number is 42.

JG: Exactly. Measurement processes often face criticism, right? Some people see them as an unnecessary burden with no real benefit. But Agile has shown us that using the right metrics makes a difference.

Lord Kelvin said, “If you cannot measure it, you cannot improve it.” Do you think this still holds true today?

LB: Absolutely yes, and for a very simple reason: If you don’t know how much something is worth—its quantity—you can’t know how long it will take.

And if you don’t know that, or who’s going to work on it, you don’t know how much it will cost, nor what price to charge if you’re a supplier. Or how much to pay if you’re a customer.

We call it the QTC flow: from quantities to time, and from time to cost.

Another thing we recommend to both the metrics and non-metrics communities is to use measurements to determine the correct time, considering the assigned team’s cost mix.

Consider the skill mix, the average daily rate, and then set a market price. That’s what we call the ABC model.

JG: Perfect. This first GUFPI-ISMA event of the year has been a great success, and this year it’s sponsored by Quanter, one of the first tools to integrate AI into the estimation process.

From your perspective as a metrics expert, how should professionals integrate metrics into their day-to-day work? Any advice, besides using Quanter Smart AI Estimation, of course?

LB: Obviously! Having good prompt engineering practices is essential.

Today, even though it’s not recorded in this interview, we generated songs with AI. We created multiple versions using prompts with fewer than 10 words—and the effect, according to the audience, was fun, enjoyable, and effective.

Generating and structuring requirements is becoming a key asset for any business analyst who, with metrics skills, can use AI to accelerate timelines—as long as they understand how to interact with the machine.

As someone said in one of today’s talks: it’s about human-AI interaction, not just human-machine interaction. And that’s clearly the way forward.

JG: Yes, we could say that AI won’t replace people, it will enhance them. Thanks.
In that context, how do you see the impact of AI on software development? For example, with code generation assistants or test automation. What impact do you think this will have on traditional metrics like IFPUG Function Points or SNAP?

LB: As mentioned in many talks today and in past events, we need to stay aware of AI hallucinations.

At ISBSG, we’ve proposed the hashtag #datahallucination.

It’s about making sure that unverified values for productivity, size, or effort don’t make it into tenders or technical specs if they don’t align with real-world conditions.
Training machine learning models also has a cost, which is why the full lifecycle needs to be reconsidered.

We must shift costs toward earlier phases, reducing them later during implementation.
We’re talking about cost redistribution, not small savings—that’s clear.

Also, as with any tool, AI shouldn’t be seen as a substitute for humans, but rather as a tool that remains under human control.

JG: Thank you, Luigi. Do you think these metrics will remain applicable as they are, or will they need to be adapted to this new AI-driven context?

LB: Functional size measurement dates back to 1979 with Albrecht and is still a process metric, meaning it’s technology independent.

The mistake is to think that productivity is solely tied to size, when in fact it’s about the relationship between size and time.

So measuring functionality will continue to be a stable process.

What will change is the technique: IFPUG, COSMIC, NESMA, FISMA, Mark II…, but the approach will remain.

What will evolve, even within IFPUG, is that while developing and updating SNAP, we’ll need to consider more and more the quality of data, as defined in ISO 25012 (not yet strictly included in the model), and also ISO 25059.

So we’ll likely see evolutions within the SNAP model.

JG: OK, perfect. Thank you, Luigi. New approaches to programming are emerging, like Vibe Coding, where AI generates code from natural language descriptions.

Do you think we’ll also see a Vibe Estimation, where a metrics expert coordinates AI assistants to produce estimations?

LB: That will always depend on costs and the cost-benefit ratio.

At first, some companies will invest more to create tools that, in a way, act as assistants to other stakeholders.

And it will largely depend on the volume of data and the cost to train a system that can be resold at the right price.

The challenge will always be in verifying the correctness of the input data—which isn’t about code quality or AI quality (which is still software), but rather data quality, which will still need to be verified manually.

JG: OK, perfect. One last, and hardest, question to wrap up: Inter or Milan?

LB: Inter. May 31, Monaco.

JG: Thank you, Luigi. A real pleasure.

LB: Thank you all.