Lesson 2 — Estimation Techniques¶

At a glance

Module: 07 — Cost & Estimation
Level: Intermediate
Estimated time: 45 minutes
Example project: the LMS and the analytics dashboard

Learning objectives¶

By the end of this lesson you should be able to:

Apply analogous, expert-judgement, parametric, and agile estimation techniques.
Explain what function point analysis measures and why it is size-based.
Produce a three-point estimate and interpret its range.
Triangulate estimates from more than one technique and reconcile the differences.

Prerequisites¶

Lesson 1 — Effort and Cost Estimation

Introduction¶

There is no single correct estimation technique. Each works well under different conditions, and each has a characteristic failure mode. The professional skill is choosing a technique that matches what you know, and then checking it with a second one.

This lesson covers four families of technique, applies them to the same piece of work, and shows why disagreement between them is useful rather than embarrassing.

1. Analogous estimation¶

Analogous estimation uses a comparable past project as the basis, adjusting for known differences.

Works when: you have genuinely similar past work and records of what it actually took.
Fails when: the projects are only superficially similar, or when the past made the same mistake your current estimate is about to make.

The technique is fast and needs little detail, which makes it the right choice for a very early estimate. Its accuracy depends entirely on the quality of the historical record — which is one of the strongest arguments for recording actual effort on every project you run.

2. Expert judgement¶

Expert judgement draws on the experience of people who have done the work. Deliverable-based, it is often the most accurate technique available for unusual work.

Works when: several experienced people estimate independently and then reconcile.
Fails when: one person estimates alone under time pressure, or when the estimate is given to a more senior person who anchors everyone on their number.

The known hazard is anchoring: the first number spoken dominates the discussion. Reduce it by collecting estimates independently and in writing before anyone speaks. As the estimator, you should be aware of the opposite effect too — a number you know someone wants to hear is the number most likely to come out.

3. Parametric and size-based estimation¶

Parametric estimation uses a formula relating size to effort. The most rigorous form in software is function point analysis, standardised by the International Function Point Users Group (IFPUG).

Function points measure the functional size of a system from the user's point of view, rather than counting lines of code — which matters because lines of code vary enormously between languages and styles for the same functionality.

The method counts two kinds of element:

Kind	Examples
Data functions	Internal logical files, external interface files
Transaction functions	External inputs, external outputs, external inquiries

Each element is rated low, average, or high for complexity, and the count is combined into an unadjusted function point count. A separate set of general system characteristics produces a value adjustment factor, giving the final adjusted count.

Those weights and characteristics come from the IFPUG counting manual; the method is applied consistently from the manual rather than from memory, and practitioners are certified in it.

The power of function points is that the size measure is technology-independent, so historical productivity data — function points per person-month — becomes comparable across projects and technologies. The weakness is that a function point count needs a defined set of requirements, so it is not available early. COSMIC is a newer, related sizing standard used in some domains.

4. Agile estimation¶

Agile teams estimate in relative rather than absolute terms.

Story points rank items by comparative effort, complexity, and uncertainty. They are deliberately not hours.
Planning poker gathers independent estimates from the whole team and discusses disagreements. The discussion is the actual value; the number is a by-product.
Velocity is the observed rate at which a team completes points. Because it is measured, it can forecast; because it is team-specific, it must not be compared between teams.
Affinity estimation sorts many items by relative size quickly by placing them on a scale.

The virtue is that relative judgement is more reliable than absolute judgement, and velocity is a measurement rather than a prediction. The hazard is point inflation: if points are converted to hours for reporting, they become hours, and the relativism that made them useful is lost.

Choosing a technique¶

Technique	Needs	Good for	Main failure mode
Analogous	Historical records, similar project	Very early estimates	False similarity
Expert judgement	Experienced estimators	Unusual work	Anchoring, single-voice estimates
Function points	Defined requirements	Comparable sizing, contracting	Needs requirements; counting skill required
Agile points and velocity	A working team, some history	Iterative delivery	Point inflation; cross-team comparison

Key terms¶

Term	Meaning
Analogous estimation	Estimating from a comparable past project
Expert judgement	Estimating from the experience of practitioners
Parametric estimation	Estimating from a formula relating size to effort
Function point	A unit of functional size measured from the user's perspective
Story point	A relative unit of effort, complexity, and uncertainty
Velocity	The rate at which a team completes story points
Anchoring	Over-reliance on the first number presented
Three-point estimate	An estimate expressed as optimistic, most likely, and pessimistic

Worked example¶

Task: estimate the "grading view" activity — an interface where a marker sees all submissions for an assignment, opens each, enters a mark, and adds feedback.

Step 1 — Analogous estimate. A previous project included a marker interface for quizzes that took 3 days. The new one shows all submissions at once and supports file downloads, so adjust upward: 4 days. Assumption: the data model is already agreed.

Step 2 — Expert judgement. Two developers estimate independently before discussing. They say 3 and 5 days. Discussion reveals one assumed they could reuse the quiz interface's table component and the other assumed it would be rebuilt. That disagreement is the finding — and it is a design decision to settle, not merely a number to average. Reconciled: 4 days with reuse.

Step 3 — Function point view. Count the transaction functions: an external inquiry listing submissions; an external input for the mark; an external input for feedback; an external output for the confirmation. Data functions: the submission file (read) and the mark record (read/write). A full count requires applying the IFPUG complexity ratings and the value adjustment factor. The point of doing it here is not the number: it is that the count depends on the requirement, not on the choice of framework — which is exactly what makes resulting productivity data comparable across projects.

Step 4 — Three-point estimate. Optimistic 3, most likely 4, pessimistic 8 (if the access-rule integration proves tangled). A widely used approximation of the expected value is (optimistic + 4 × most likely + pessimistic) ÷ 6, giving (3 + 16 + 8) ÷ 6 = 4.5 days.

Step 5 — Report. "Grading view: 4.5 days expected, 3 days if reuse works cleanly, up to 8 days if the access-rule integration is complex. Assumes the data model is settled."

Step 6 — Note what made the range wide. The pessimistic case is not extra work; it is a decision not yet made. Narrowing ranges is usually an act of design, not of estimation.

Common misconceptions¶

“Story points are hours in disguise”

They are relative and team-specific. Converting them to hours destroys the property that made them useful, and comparing velocity between teams compares the teams' scales, not their productivity.

“Function points measure complexity”

They measure functional size from the user's perspective. Two systems of equal size can differ greatly in technical complexity — which is one reason the value adjustment factor exists.

“Averaging several estimates gives the true value”

Averaging is useful for smoothing noise, but disagreement often indicates a genuine unresolved question. Investigate the difference before averaging it away.

Practical activity¶

Estimate the same work three ways. Pick one activity from an example project of moderate size.

Produce an analogous estimate, naming the past project and the adjustment you made.
Collect two independent expert estimates from classmates, in writing, before discussing.
Produce a three-point estimate and compute the expected value.
Compare the three and write down what the disagreement tells you about the requirement.

What "good" looks like: the analogous estimate names its comparison and its adjustment; the expert estimates were genuinely independent; the reconciliation identifies an assumption or design decision rather than simply averaging.

Self-assessment¶

Why do function points allow productivity comparison between projects written in different languages, while lines of code do not?
What is anchoring, and what practical step reduces it?
What does a wide three-point range usually indicate, and what should be done about it?
Apply it — LMS migration. The prime estimator has left. Two experienced people estimate the same migration work package at six weeks and fourteen weeks. A similar migration a year ago has recorded actuals. The sponsor wants one number.

Hint: A strong answer says what you do with the disagreement, which techniques you combine, and how the final figure is expressed.

Show answers

Because a function point counts functional size from the user's perspective — the same requirement yields approximately the same count regardless of implementation technology. Lines of code depend heavily on language, framework, and style, so the same functionality produces very different counts.
Anchoring is over-reliance on the first number presented, which then pulls every subsequent estimate toward it. Reduce it by collecting estimates independently and in writing before the group discusses any of them.
Usually that a significant assumption or design decision is unresolved, not that the estimator was vague. The correct response is to resolve the question — a prototype, a design decision, or a spike — and re-estimate; the range should narrow as a result.
Do not average the two numbers before understanding them: find out whether they differ because of different assumptions (one may be estimating the migration tooling that the other assumes exists, or one may be giving effort and the other duration). Then triangulate. Use the recorded actuals from last year's migration as an analogous estimate, adjusted for the known differences. Ask for a three-point estimate on the parts with no history — optimistic 6, most likely 9, pessimistic 14 — whose expected value is (6 + 4×9 + 14) ÷ 6 ≈ 9.3 weeks, with the spread 6–14 carrying the real information. Use expert judgement only where no history exists, and record whose judgement it was. Present one figure as a range with its basis: “one quarter, most likely nine to ten weeks, up to fourteen if the legacy data is worse than last year's”. The widening range where the two estimators disagree is a finding, not a failure.

Summary¶

Analogous estimation is fast and needs history; expert judgement suits unusual work; parametric methods need defined requirements; agile methods need a working team.
Function points measure functional size independently of technology, which makes historical productivity data comparable.
Story points are relative and team-specific; converting them to hours defeats their purpose.
Three-point estimates communicate uncertainty, and a wide range usually signals an unresolved decision rather than a poor estimator.
Triangulating with a second technique is the cheapest available check on an estimate.

Further learning¶

Module 08 — Risk Management turns the optimistic and pessimistic cases into a risk register.
Module 04 — Agile & Scrum covers velocity and backlog refinement in context.
Software Estimation: Demystifying the Black Art, Steve McConnell.
International Function Point Users Group (IFPUG) — counting practices manual and certification.

Next¶

You have completed Module 07. Continue to Module 08 — Risk Management.