Story Points vs. Function Points (FP): Evaluating the Systemic Risk of Using Team-Relative, Semiquantitative Sizing

Introduction
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.


Story Points: A Team-Relative Estimation Tool
Story Points are an Agile estimation technique that originated in Extreme Programming (XP). Teams assign a relative value (e.g., 1, 2, 3, 5, 8) to each user story based on complexity, effort, and uncertainty. Key characteristics include:

• Subjectivity: Each team calibrates Story Points according to their experience, skills, tools, and context.
• Semiquantitative: Story Points are not based on absolute units; they are meant for comparative sizing within a team.
• Internal Use: Intended for sprint planning and forecasting, not external comparison or contractual guarantees.

Story Points help teams predict how much work a team, not a ‘developer’, can deliver in a Sprint, enabling adaptive planning and continuous improvement. However, their subjectivity means that a "5" in one team, even for a member of the same team, could be a "2" or "8" in another team or for another member of the same team. This relativity is by design, supporting team autonomy and learning.


Function Points: Objective, Standardised Measurement
Function Points (FP) provide a standardised, technology-agnostic way to measure the functional size of software. Developed by Allan Albrecht at IBM in the 1970s, Function Point Analysis (FPA) counts the number and complexity of features delivered to the user, such as inputs, outputs, data files, and interfaces.
Key attributes of Function Points:

• Objectivity: Based on a standardised set of rules, minimising subjectivity.
• Comparability: Allows for benchmarking across projects, teams, and organisations.
• Vendor-Neutral: Useful for contracts, outsourcing, and fixed-price agreements.
• Predictive Power: Correlates with actual effort and cost more reliably than team-relative metrics.

Function Points support external accountability, making them suitable for formal cost estimation, vendor negotiations, and performance measurement.


The Systemic Risk: Using Story Points for Fixed-Price Contracts
The Temptation
Agile’s popularity—and the ease of assigning Story Points—tempts organisations to use these metrics for more than their intended purpose. Project Managers, Program Managers and procurement teams sometimes attempt to translate Story Points into contractual obligations, using them to estimate costs and set fixed prices for software delivery.
The Problem
This approach introduces systemic risk on multiple fronts:

1. Lack of Standardisation: Story Points are not comparable across teams or organisations. One vendor’s 100 Story Points may represent vastly more or less work than another’s.
2. Gaming the System: When money is at stake, teams may inflate or deflate Story Point estimates to protect themselves or win contracts, undermining trust and data integrity.
3. Scope Creep and Disputes: Ambiguous sizing leads to frequent disagreements about what was promised versus what was delivered, leading to scope disputes and legal conflicts.
4. Undermined Delivery: Teams pressured to meet Story Point targets may cut corners, sacrificing quality to meet arbitrary numbers.

Systemic Impact
When Story Points are used as the basis for hard, contractual commitments:

• Cost Overruns become more likely as estimates fail to account for real-world differences in team calibration.
• Litigation Risk increases as customers and vendors dispute sizing and delivery.
• Relationship Breakdown occurs as distrust grows between parties.
• Market Instability emerges if the practice becomes widespread, leading to industry-wide cost estimation failures.

Why Function Points Work Better for Contracts
Function Points sidestep many of these pitfalls:

• Standard Definitions: Independent auditors can verify FP counts, reducing disputes.
• Historical Data: Industry benchmarks allow for more accurate cost and effort estimation.
• Transparency: Both customer and vendor can agree on the scope up front, reducing the risk of misunderstandings.
• Fairness: Payments and penalties can be tied to objectively measured deliverables, not team-relative guesses.

While FPA has its own learning curve and requires specialised expertise, its rigour pays dividends in contractual settings where accountability, comparability, and objectivity are paramount.


Best Practices: Choosing the Right Metric for the Right Job

1. Use Story Points for Internal Planning: Let teams estimate, forecast, and improve using their own sizing—never for external commitments.
2. Adopt Function Points for Contracts: Where work is to be delivered under fixed-price or fixed-scope agreements, use FP or a similarly objective metric.
3. Educate Stakeholders: Ensure all parties understand the differences, limitations, and appropriate applications of each metric.
4. Avoid Metric Translation: Don’t attempt to convert Story Points to hours, dollars, or Function Points. Each metric has its own context and meaning.
5. Encourage Transparency: Clearly document estimation methods and review them regularly to ensure fairness and integrity.

The bottom line
Story Points and Function Points each have their place in modern software development. Story Points enable Agile teams’ adaptability and learning, but their subjectivity makes them unsuitable for high-stakes contractual cost estimation. Function Points, while not perfect, offer the objectivity and comparability needed to underpin reliable, fair, fixed-price contracts.
Attempting to use team-relative, semiquantitative sizing for contractual obligations introduces systemic risk: cost overruns, legal disputes, and project failure. By respecting the strengths and limitations of each metric, organisations can deliver value, build trust, and avoid the pitfalls of metric misapplication in software development contracts.

Question for readers:
-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?
Share your thoughts and join the conversation below.