Reconciling Software Estimates: LOC, FP, UCP, and Agile Story-Based Methods

Written by Rohan Nandan on April 24, 2026 · 4 min read

Reliable software planning depends on estimation quality. One estimate is rarely enough. In practice, teams increase confidence by producing multiple estimates, comparing them, and reconciling differences before committing to budget and schedule.

Why Reconciliation Matters

A core planning principle from your notes is simple:

• Every estimation technique should be cross-checked with at least one other approach.
• Multiple estimates must be compared and reconciled.
• If estimates converge, confidence in reliability increases.

When estimates diverge widely, two root causes are common:

1. Project scope is misunderstood or misinterpreted.
2. Productivity baselines are inappropriate or misapplied.

This makes reconciliation a quality-control activity, not an optional reporting step.

Problem-Based Estimation

LOC and FP are used in two ways:

1. As sizing variables for software elements.
2. As baseline productivity metrics from historical projects.

A practical workflow:

1. Start with bounded scope.
2. Decompose scope into estimable functions.
3. Estimate LOC or FP per function.
4. Apply baseline productivity metrics (for example LOC per person-month or FP per person-month).
5. Derive cost and effort for each function.
6. Aggregate into project-level estimate.

Important cautions from your notes:

• Use a taxonomy of project types when collecting productivity data.
• Include infrastructure software effort, not just user-visible functionality.

LOC-Based Estimation Example

Given:

• Average productivity: 620 LOC per person-month
• Burdened labor rate: $8,000 per month
• Approximate cost per LOC: $13

Lecture outcome:

• Estimated cost: $431,000
• Estimated effort: 54 person-months

This method is direct and useful when historical LOC productivity is trustworthy and scope granularity is clear.

FP-Based Estimation Example

Function-point estimate equation:

$$FP_{estimated} = count_{total} \times [0.65 + 0.01 \times \sum F_i]$$

Using the lecture values:

• $count_{total} = 320$
• $\sum F_i = 52$
• Adjustment factor $= 0.65 + 0.01 \times 52 = 1.17$

So:

$$FP_{estimated} = 320 \times 1.17 = 375$$

With historical cost per FP of $1,230:

• Estimated cost: $461,000
• Estimated effort: 58 person-months

FP is often useful when teams need size estimation that is less tied to implementation language detail.

Process-Based Estimation Example

Process-based estimation starts from project scope, then maps functions to framework activities. Effort is placed in a function-by-task matrix, and labor rates are applied to total activity effort.

Lecture outcome with average labor rate of $8,000 per month:

• Estimated cost: $368,000
• Estimated effort: 46 person-months

This approach can expose where effort is concentrated across communication, modeling, construction, testing, and other process activities.

Use Case Point Estimation (UCP)

UCP incorporates:

• use case count and complexity,
• actor count and complexity,
• technical complexity factors,
• environment complexity factors.

General equation:

$$UCP = (UUCW + UAW) \times TCF \times ECF$$

Where:

• $UUCW$: unadjusted use case weight
• $UAW$: unadjusted actor weight
• $TCF$: technical complexity factor
• $ECF$: environment complexity factor

Worked CAD Example from Notes

Given:

• $UUCW = 470$
• $UAW = 44$
• $TCF = 1.04$
• $ECF = 0.96$

Then:

$$UCP = (470 + 44) \times 1.04 \times 0.96 = 513$$

If productivity is 85 LOC per UCP:

$$Estimated\ LOC = 85 \times 513 = 43,605 \approx 43,600$$

Using 620 LOC per person-month and $8,000 labor rate with approximate $13 per LOC, lecture outcomes are:

• Estimated cost: about $552,000
• Estimated effort: about 70 person-months

Agile Project Estimation Steps

The agile estimation flow in your notes emphasizes user-story granularity:

1. Estimate each user story separately.
2. Decompose each story into engineering tasks.
3. Estimate each task individually, or estimate story volume in LOC, FP, or use case count.
4. Sum tasks for story effort, or convert volume using historical productivity.
5. Sum story efforts to estimate increment effort.

This approach supports iterative planning and faster re-estimation when backlog priorities shift.

How to Reconcile Different Estimates

A practical reconciliation workflow:

1. Validate scope and decomposition assumptions.
2. Check historical productivity source and project-type match.
3. Compare estimate spread across methods.
4. Investigate outliers rather than averaging blindly.
5. Document assumptions and uncertainty bands.
6. Re-estimate after major scope updates.

Reconciliation is strongest when it is transparent and repeatable.

Conclusion

Estimate reliability comes from triangulation, not precision theater. LOC, FP, process-based, UCP, and agile story-based methods each reveal different aspects of project effort. The planning discipline is to compare them, explain differences, and commit only after reconciliation. That is the foundation of credible software cost and schedule planning.