05 Size Estimation: What Function Points Still Measure

Learning objectives

After this chapter you should be able to:

1. Count the function points of a small specification using IFPUG ratings and weights, and convert the count to lines with a stated ratio.
2. Explain the lines-of-code paradox, and why function points never measured code.
3. Separate measuring functional size from predicting effort, and use the negation test to show where the prediction fails.
4. Distinguish lines generated, lines presented for review and lines delivered, and define the size of the verification job.
5. Forecast functional size and verification size together before construction, and record both.
6. State what evidence would overturn the verdict.

Opening case

A composite case, not a real engagement.

Graham directs an internal engineering group of five at a mid-sized manufacturer. For years his dashboard has shown one productivity number: lines of code merged per engineer per month, about 1,800. It is free to collect and stable.

The chapter continues from here.

What the chapter covers

1. 5.1 The classical method
   • 5.1.1 Why measure size at all, and what it is for
   • 5.1.2 Lines of code and its problems
   • 5.1.3 Function points
   • 5.1.4 Counting under the IFPUG rules
   • 5.1.5 Adjusted counts, and COSMIC
   • 5.1.6 Story points and relative sizing
   • 5.1.7 Converting to lines: backfiring and gearing factors
   • 5.1.8 A worked example: counting Dispatch
2. 5.2 The assumption it depends on
3. 5.3 What agents change
   • 5.3.1 Lines: three quantities that used to be one
   • 5.3.2 Function points: what survives and what does not
   • 5.3.3 The size of the verification job
   • 5.3.4 Story points
4. 5.4 The verdict
5. 5.5 What replaces it: two sizes, recorded together
   • 5.5.1 The two sizes
   • 5.5.2 Forecasting verification size early
   • 5.5.3 Record, then calibrate
   • 5.5.4 What the replacement keeps
6. 5.6 Lab: Count your own project
7. 5.7 What would make this verdict false

Lab and prediction

The lab tests this prediction from the working paper the book grows from (Smith 2026a):

• P3 Function-point counts correlate with total human hours more strongly than delivered LOC does

This chapter's own prediction: Specification hours track function points more closely than lines, and review hours track lines presented more closely than function points.

A result that contradicts a prediction, honestly reported, is a result. You are graded on accurate records and reasoned interpretation, not on agreeing with the book.

Summary

• Measuring functional size and predicting effort are separate jobs. Function points measure functional size from the specification; Dispatch comes to 120 unadjusted function points, about 6,000 lines of Java at an illustrative 50 lines per point.
• Load-bearing assumption: product size predicts effort. The same functional size can need very different review and verification (9,000 against 18,000 lines presented for 6,000 delivered), so one size times a steady rate fails. That does not show that every size-based model fails.
• Verdict: breaks (partly). Functional size survives as a measurement; a fixed delivered-lines rate no longer predicts effort under the specified workflow; story points recalibrate, and velocity counts what a team's definition of done counts.
• Replacement: record functional size (specification effort, scope) and the size of the verification job, the pair (R, P) of first-pass lines presented and acceptance properties (review and verification effort). Forecast both before building, then calibrate on the log.

Key terms

Functional size / function point (FP)

size measured by the functions users require (ISO/IEC 14143-1); IFPUG's unit, counted as unadjusted function points (UFP).Also used in 2, 3, 6

COSMIC Function Point (CFP)

one data movement of one data group (ISO/IEC 19761).

Lines-of-code paradox

more expressive languages show lower lines per staff-month because fixed costs spread over fewer lines.

Gearing factor / backfiring

average source lines per function point for a language; applied in reverse to estimate function points from code.

Lines generated / presented for review / delivered

all lines an agent produces; lines first submitted to a reviewer; lines merged and kept.Also used in 2, 3, 6

Size of the verification job

the pair (R, P) of first-pass lines presented and acceptance properties to be checked.

Connections

Where this chapter and another point to each other most often.

• Chapter 2: The Assumption Audit: A Method That Outlasts the Tools
  Apply the negation test (Section 2.3): if the rate is no longer constant, a size alone does not predict effort, and the method keeps producing numbers that look as confident as before.
• Chapter 6: Cost and Schedule Estimation After COCOMO
  Table 5.2 gives the rating scheme as the COCOMO II manual reproduces it (USC CSE 1997, version 1.4, not the 2000 edition that Chapter 6 uses), and Table 5.3 gives the weights.
• Chapter 16: Roles and the Four Conditions for Assurance
  The count is checkable, which makes this a good early role under Chapter 16's conditions.

See it on the map

Further reading

• Albrecht (1979), "Measuring Application Development Productivity." The origin of function points, built to compare productivity across languages.
• Kemerer (1987). An independent test of four effort models on real projects, and a model of how to validate a size measure against effort.
• Jones (2012). The lines-of-code paradox with the PBX table. Read it critically: the author advocates the alternative, and the underlying study is not available.