8.2 Estimation Methods

Estimation is not fortune telling. It is a revisable judgment based on prior experience, current uncertainty, and how well the team can slice work.

The goal is not to make every number exact. The goal is to discover earlier when something is more complex than it looks.

Story Points And Relative Estimation

Story points usually express relative size, complexity, and uncertainty. They are not hours, and they should not be used to rank individuals.

Relative estimation depends on reference cards:

• 1 point: very small, clear pattern, almost no dependency.
• 3 points: ordinary work with a few boundaries.
• 5 points: multiple modules or acceptance paths.
• 8 points: clear unknown, integration, or migration.
• 13 points: probably too large; split or spike first.

Without reference cards, estimation meetings become arguments from feeling.

Function Points And COCOMO

Function Points try to estimate system size from inputs, outputs, queries, files, and interfaces. COCOMO is a historical model that estimates cost from size, complexity, and team factors.

Their value is a reminder: estimates are shaped by more than code volume. Complexity, experience, tools, constraints, and quality requirements matter. They should not be treated as mechanical answers for modern product teams.

Estimation Error Should Be Reviewed

Being wrong is not failure. Refusing to learn is failure. Estimation error may come from:

• Hidden dependencies.
• Unclear acceptance criteria.
• More fragile legacy code than expected.
• Ignored data migration or environment cost.
• Work too large to learn from early.

Record error as reference material, and the team gets better. Estimation skill is calibrated, not argued into existence.