Stelian ROMANProject Manager| MicroSafetyCarlingford, New South Wales, Australia
In software development, regardless of the delivery approach, accurately sizing work is crucial for planning, budgeting, and delivery. Nowadays, product and project teams are most of the time temporary, unlike the 1990s internal development teams with members working together for decades, and sometimes retiring from the same organisation that they joined as university graduates. Two widely discussed approaches are Story Points—a team-relative, semiquantitative Agile metric—and Function Points (FP), a more standardised, objective sizing method. While both have their place, the choice between them becomes critically important when organisations use these metrics for high-stakes decisions, such as hard fixed-price contractual cost estimates. This blog post looks at the Story Points and Function Points, highlighting the systemic risks of misapplication, and why using team-relative measures for contracts can be a recipe for disaster.
-What is your experience with using story points or function points in cost estimation and contracts?
-Have you encountered challenges or successes with these metrics in real-world projects?
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
An insightful post and an important reminder that metrics should be used within the context for which they were designed.
In my experience, Story Points can be highly effective for team-level planning, forecasting, and continuous improvement, while Function Points provide a stronger foundation for benchmarking, external comparison, and contractual discussions. Difficulties often arise when organizations attempt to use one metric to serve purposes it was never intended to support.
One additional perspective may be worth exploring. Many estimation failures are not caused by Story Points themselves, but by the nature of the systems we are trying to estimate. Uncertainty, evolving requirements, external dependencies, delayed decisions, and organizational complexity can undermine even the most disciplined measurement approaches.
Perhaps the deeper challenge is that every metric is ultimately an imperfect representation of reality. The limitation often lies less in the metric itself and more in the complexity of the environment being measured. Understanding that distinction may be just as important as choosing between Story Points and Function Points.
Exploring this dimension could elevate the discussion from a comparison of sizing techniques to a broader conversation about complexity, governance, and decision-making under uncertainty.
Also, a small technical note: the blog link currently appears to return a "400 Bad Request" error, so readers may have difficulty accessing the full article.
Thank you for raising an important topic that continues to generate valuable discussion across the profession. Saving Changes...
Stelian ROMANProject Manager| MicroSafetyCarlingford, New South Wales, Australia
Luis Branco Thank you for the technical note. it is an undocumented feature :). Sometimes work and sometimes it doesn't. I avoided using short links because I want to be evident that the blog post is on projectmanagement.com, it is an extension of the question. I tried to use short links but they won't work either.
As a workaround I will mention the title of the blog post. Saving Changes...
Stelian ROMANProject Manager| MicroSafetyCarlingford, New South Wales, Australia
Luis Branco I was fortunate to be involved in function points initiatives. Like Six Sigma tools and practices, they are at a different level than the software version of Agile compared with Agile Manufacturing. I agree that story points are a good tool for team to improve their processes, including estimation skills, but when they are reverted to the original 'ideal days', as an obfuscation of time they lose most of their value as a team tool. Saving Changes...
Stelian ROMANProject Manager| MicroSafetyCarlingford, New South Wales, Australia
Luis Branco "Many estimation failures are not caused by Story Points themselves, but by the nature of the systems we are trying to estimate.", I agree. I would like to add that although Scrum can be used outside software development, story points, not a Scrum practice but very few remember XP :), can be used ONLY for software development. Saving Changes...
Stelian ROMANProject Manager| MicroSafetyCarlingford, New South Wales, Australia
Luis Branco "metric itself and more in the complexity of the environment being measured." What metric we use is also dependent on what we want to do with the result. SP are a good starting point for a team of software developers, and their purpose is to learn how to estimate and plan. Developers are optimistic by definition because (almost) everything can be done having unlimited time and budget. Function points are the best option for benchmarking (independent on industry, organisation, team, technology) and for commercial engagements for large software development projects. As you said, each of them brings value only "within the context for which they were designed". Saving Changes...
Ming YeungAdjunct Professor| George Brown Polytechnic/Fanshawe College/Humber PolytechnicToronto, Ontario, Canada
My experience with story points and function points in cost estimation has taught me that the metric itself is rarely the problem; it’s how organizations use it. Story points work well as an internal forecasting tool when a stable team uses them to understand relative complexity and plan iteratively. But the moment they’re pulled into fixed‑price contracts or executive‑level cost commitments, the cracks show quickly. As story points are inherently team‑relative, two teams can assign wildly different values to the same work, making them a risky foundation for contractual estimates or vendor negotiations. I have seen this play out firsthand. In one project, leadership attempted to convert story points directly into dollars for a fixed‑price bid. Despite our warnings, the estimate was accepted. The result was predictable: the vendor underbid, delivery lagged, and both sides spent months renegotiating scope and absorbing frustration. It wasn’t a failure of Agile—it was a failure of misapplied metrics. On the other hand, I’ve had success using function points when a high degree of predictability and contractual clarity was required. While FP analysis takes more upfront effort, its standardization makes it far more defensible in procurement, budgeting, and vendor management. It creates a shared language that doesn’t depend on team history or velocity.
...
1 reply by Stelian ROMAN
Sep 08, 2026 6:23 PM
Stelian ROMAN
...
Thank you, Ming. You raised a very good point. I've seen Function points used very well to award contracts. There are 2 reasons for that: they are an objective measure, independent of the context, and the counting is done by an independent person/organisation, not by the client or vendor. There are a couple of challenges: Good FP counters are hard to find and expensive; FP were not designed for the modern architectures.
Saving Changes...
Stelian ROMANProject Manager| MicroSafetyCarlingford, New South Wales, Australia
Jun 26, 2026 11:23 PM
Replying to Ming Yeung
...
My experience with story points and function points in cost estimation has taught me that the metric itself is rarely the problem; it’s how organizations use it. Story points work well as an internal forecasting tool when a stable team uses them to understand relative complexity and plan iteratively. But the moment they’re pulled into fixed‑price contracts or executive‑level cost commitments, the cracks show quickly. As story points are inherently team‑relative, two teams can assign wildly different values to the same work, making them a risky foundation for contractual estimates or vendor negotiations. I have seen this play out firsthand. In one project, leadership attempted to convert story points directly into dollars for a fixed‑price bid. Despite our warnings, the estimate was accepted. The result was predictable: the vendor underbid, delivery lagged, and both sides spent months renegotiating scope and absorbing frustration. It wasn’t a failure of Agile—it was a failure of misapplied metrics. On the other hand, I’ve had success using function points when a high degree of predictability and contractual clarity was required. While FP analysis takes more upfront effort, its standardization makes it far more defensible in procurement, budgeting, and vendor management. It creates a shared language that doesn’t depend on team history or velocity.
Thank you, Ming. You raised a very good point. I've seen Function points used very well to award contracts. There are 2 reasons for that: they are an objective measure, independent of the context, and the counting is done by an independent person/organisation, not by the client or vendor. There are a couple of challenges: Good FP counters are hard to find and expensive; FP were not designed for the modern architectures. Saving Changes...
