Estimation: sizing, decomposition, and reconciling

The thinking move: an estimate is a distribution, and one estimate is not an estimate

Estimation is where planning stops being tidy. Everything about it is risk-laden: project complexity, the size of the thing, the degree of structural uncertainty, how much of it has been built before by these people. The naive response is to produce one number and defend it; the engineering response is to produce several numbers by independent routes and then explain the disagreement. That is the single most valuable habit in this lesson and the one the exam rewards, because a candidate who writes "I would apply at least two techniques and reconcile them" has said something a candidate reciting the function-point weights has not.

The mechanism underneath every technique is the same. Bound the scope. Decompose it into functions small enough to be sized individually. Choose an estimation variable — lines of code, function points, use case points, story points — and size each function in it, three times: optimistic, most likely, pessimistic, combined by the weighted average S = (s_opt + 4 × s_m + s_pess) / 6. Then apply baseline productivity data from your own past projects, expressed in the same variable, to convert size into effort, and sum. The techniques differ only in what they count and how early they can count it. Carry the range forward as well as the point: a function whose optimistic and pessimistic sizes differ threefold is telling you it is not understood yet, which is a risk finding rather than an estimation one.

Problem-based: LOC and function points

LOC-based estimation sizes each function in lines of code and applies a baseline of lines per person-month. It is concrete and easy to check afterwards, and it has two well-known defects: it is language- and style-dependent, and it cannot be done until the design is detailed enough to guess at implementations. Function-point estimation sizes the same functions from the requirements model instead, by counting five information-domain values — external inputs, external outputs, external inquiries, internal logical files and external interface files — weighting each as simple, average or complex, then adjusting the total by complexity factors. Its advantage is decisive for planning: it is available before a line of code exists and is independent of implementation language. Its cost is that counting is partly subjective, so two planners can differ.

Process-based, use case points, and the agile cross-check

Process-based estimation turns the problem sideways: instead of estimating the product, estimate the effort per framework activity per function. You build a grid — functions down the side, communication, planning, modelling, construction and deployment across the top — and fill in person-months per cell. It is the most commonly used technique in practice because it prices the work you will actually do, including the modelling and deployment effort that LOC-based estimates quietly assume away.

Use case points size the system from the use case model: each use case is classed simple, average or complex and weighted 5, 10 or 15 to give an unadjusted use case weight; each actor is classed and weighted 1, 2 or 3 to give an unadjusted actor weight; and the sum is scaled by technical and environmental complexity factors. Agile estimation drops absolute units entirely — the team sizes stories in story points, a relative unit, and divides by its measured velocity (points completed per sprint) to get elapsed sprints. It is fast and self-calibrating, and it silently omits any work that never became a story.

Empirical estimation models take the same idea one step further and hand the conversion to a published formula fitted to historical project data, of the general shape effort = A × size^B × M — a constant, the size raised to an exponent that captures diseconomy of scale, and a multiplier assembled from project attributes. The best known is COCOMO II (the constructive cost model, second generation), which is really three models used at three different moments: an application composition model for early prototyping work, sized in object points; an early design model for the point at which requirements are stable but the architecture is not, sized in function points; and a post-architecture model for once the architecture exists, sized in lines of code or function points and adjusted by seventeen cost drivers plus five scale factors. Its value is that it makes the assumptions explicit and auditable; its limitation is the one every empirical model has — the coefficients were fitted to somebody else’s projects, so a model used without local calibration against your own completed work is quoting a stranger’s productivity as if it were yours.

Reconciling

When the numbers agree you have some reason to believe them. When they diverge widely there are only two causes worth investigating: the scope is not understood or has been misinterpreted, or the productivity data being applied is wrong for this kind of work. Find out which before averaging, because a mean of two numbers that disagree for a reason is a number that is wrong for that same reason.

Worked example — the BorrowBox reservation subsystem, four ways

The reservation subsystem covers search, hold-and-expiry, waitlist and token issue. Sized in LOC with three-point values — search (600 / 900 / 1500), hold (400 / 600 / 1000), waitlist (300 / 500 / 900), token (250 / 400 / 800) — the expected sizes are 950, 633, 533 and 442, about 2,560 LOC. At the team's own baseline of 520 LOC per person-month that is 4.9 person-months. Counted as function points the same subsystem is 4 external inputs, 3 outputs, 2 inquiries, 3 internal logical files and 1 external interface file, giving 76 unadjusted points; adjusted upward five per cent for the external hardware interface it becomes 80 FP, and at 15 FP per person-month, 5.3 person-months. The process-based grid — 0.3 communication, 0.2 planning, 1.2 modelling, 3.2 construction, 0.8 deployment — totals 5.7 person-months. Use case points give 3 average and 4 simple use cases (50 unadjusted use case weight) with 2 simple, 1 average and 2 complex actors (10 actor weight), scaled by 1.02 and 0.95 to 58 UCP, which at the team's 0.11 person-months per UCP is 6.4 person-months.

Four numbers: 4.9, 5.3, 5.7, 6.4. Treating the lowest as optimistic, the middle pair as most likely and the highest as pessimistic gives a reconciled 5.6 person-months, with a defensible range of 4.9 to 6.4. Now the interesting part. The team also sized the backlog at 46 story points and, at their velocity, expected about three sprints — roughly 4.2 person-months, some twenty-five per cent below the reconciled figure. That gap is the most valuable output of the whole exercise. Investigating it shows the backlog contains no story for the locker simulator, which the process-based grid had counted under construction because the driver cannot be built without it. The agile estimate was not wrong about the stories; it was wrong about the work.