Effort, Cost and Resource Estimation

Introduction

Software estimation is the disciplined process of predicting the effort, elapsed time, cost, people, skills, infrastructure and other resources needed to complete a software project. It is not a promise that the future will unfold exactly as predicted. Rather, it is a reasoned forecast based on available evidence, explicit assumptions and known uncertainty.

Estimation supports feasibility decisions, proposal pricing, release planning, staffing, procurement, budgeting and risk management. A poor estimate can cause underfunding, unrealistic deadlines, excessive overtime, quality problems and loss of stakeholder trust. A good estimate is transparent: it identifies what is included, explains how the estimate was produced, records assumptions and is revised when new information becomes available.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Distinguish effort, duration, cost, capacity and productivity.
2. Select and apply expert judgment, analogy and decomposition appropriately.
3. Use function points, story points and COCOMO concepts at an introductory professional level.
4. Apply three-point estimation and calculate expected effort and uncertainty.
5. Prepare a realistic budget and resource plan.
6. Recognise estimation bias, uncertainty, ethical concerns and model limitations.

1. Fundamental Estimation Concepts

1.1 Effort, duration and cost

Effort is the amount of human work required. It is commonly measured in person-hours, person-days or person-months. One person-month is not universally equal to a fixed number of calendar hours; organisations must define their working calendar.

Duration is elapsed calendar time between project start and completion. Effort and duration are related but not interchangeable. A project requiring 20 person-months may take 5 months with four suitably skilled full-time people, but not necessarily. Communication, onboarding, dependencies, leave, multitasking and sequential work affect the result.

A simple capacity relationship is:

The availability factor is between 0 and 1 and represents the proportion of working time actually available for the project. It excludes meetings, support work, leave and other commitments. This relationship is a planning approximation, not a law of delivery.

Cost is the monetary value of labour and non-labour resources. A basic labour-cost calculation is:

Here, effortᵢ is the effort assigned to role or person i, and loaded rateᵢ is the cost per unit of effort. A loaded rate may include salary, benefits, taxes, office space, equipment and organisational overhead. Units must be consistent, such as person-hours multiplied by currency per person-hour.

The total budget may be represented as:

Non-labour cost can include cloud services, licences, devices, training, travel, security testing and external services. Contingency is a controlled allowance for identified uncertainty; it should not be used to conceal arbitrary padding.

1.2 Productivity and capacity

Productivity is an output-to-effort relationship. For a size measure S and effort E, a simple productivity measure is:

The unit depends on the size measure—for example, function points per person-month. Productivity comparisons are meaningful only when teams use comparable technology, quality standards, domain complexity and measurement rules. Lines of code per person-month, for example, can encourage undesirable code expansion and does not directly measure business value.

1.3 Estimate, budget and commitment

An estimate is a forecast based on evidence. A budget is an authorised financial allocation. A commitment is a promise or contractual obligation. These should not be presented as interchangeable. Communicating an uncertain estimate as a guaranteed commitment is both professionally irresponsible and a common source of project failure.

2. Principles of Reliable Estimation

Effective estimation follows several principles:

• Define scope and the unit of measurement before calculating.
• Separate size, effort, duration and cost.
• Use more than one estimation method when the decision is important.
• State assumptions, exclusions, dependencies and confidence levels.
• Involve people who understand the work, including developers, testers, analysts and operations staff.
• Estimate the whole product lifecycle, not only programming.
• Include quality assurance, integration, documentation, deployment, training and project management.
• Record ranges rather than false precision.
• Re-estimate at milestones using actual performance data.
• Protect estimates from management pressure and optimism bias.

A useful estimate is reproducible: another competent person can understand the input data and follow the reasoning.

3. Estimation Approaches

3.1 Expert judgment

Expert judgment uses the experience of specialists to estimate work. Experts may reason from similar projects, technical complexity, team capability and risks. This method is fast and useful when requirements are incomplete, but it can be affected by anchoring, optimism, availability bias and organisational pressure.

A structured approach is preferable to simply asking, “How long will it take?” The estimator should independently record assumptions, provide a range, explain major drivers and then compare estimates in a facilitated discussion. Wide disagreement is valuable evidence that scope or assumptions require clarification.

3.2 Analogy

Analogical estimation compares the proposed project with completed projects. For example, if a previous customer portal required 12 person-months and the new portal has similar functionality but 25% more integration work, an initial estimate might be approximately 15 person-months. The adjustment is a judgment, not a guaranteed formula.

Analogy is strongest when historical projects are genuinely comparable in size, technology, team experience, quality requirements and development process. A project repository should record actual effort, delivered scope, defects, team composition and reasons for variation so that future analogies are evidence-based.

3.3 Decomposition

Decomposition breaks a project into smaller components using a work breakdown structure (WBS). Each work package is estimated, and the estimates are aggregated.

Typical decomposition levels include:

1. Product or release
2. Features or subsystems
3. Activities such as analysis, design, implementation, testing and deployment
4. Tasks small enough to be understood and monitored

For a bottom-up estimate:

where Eᵢ is the estimated effort for component i. The addition is valid when components are defined without significant overlap. Shared integration, coordination and rework must be added explicitly or included in appropriate work packages.

Decomposition reduces cognitive difficulty and exposes omissions. However, it can produce an overly confident total if every small estimate is optimistic or if cross-component dependencies are ignored.

3.4 Top-down and bottom-up estimation

A top-down estimate begins with an overall project estimate and allocates it among components. It is useful early, when details are limited, and helps assess strategic feasibility. A bottom-up estimate builds from detailed tasks and is useful when scope and solution structure are clearer. Professional practice often compares both. A large difference should trigger investigation rather than an arbitrary averaging exercise.

4. Function Point Estimation

Function points measure software size from the user’s functional requirements rather than from a particular programming language. They can support estimation before implementation technology is selected.

The traditional unadjusted function point method counts five function types:

Each function is classified as low, average or high complexity using rules concerning data elements and referenced files. The International Function Point Users Group (IFPUG) counting rules define detailed weights. A simplified standard table often used for instruction is:

The unadjusted function points are:

Some traditional variants apply a value adjustment factor based on fourteen general system characteristics:

where VAF = 0.65 + 0.01 × ΣFᵢ, and Fᵢ are characteristic ratings from 0 to 5. This adjustment is associated with the traditional IFPUG method and should not be mixed casually with other function-point variants. Modern organisations may use unadjusted counts or different standards.

Illustrative calculation. Suppose a system has 20 low-complexity inputs, 10 average outputs, 8 average inquiries, 5 high internal files and 2 low external interface files:

If an organisation has historical productivity of 8 function points per person-month, the initial effort is:

This result assumes the productivity data is comparable and that the count is reliable. Function points do not automatically account for exceptional performance, safety constraints, unfamiliar technology or poor requirements.

5. Story Points and Agile Estimation

Story points are relative units used by an Agile team to compare the size of user stories. They usually combine effort, complexity, uncertainty and sometimes risk. They are not hours and should not be converted into hours as a universal rule.

Teams commonly use a sequence such as 1, 2, 3, 5, 8 and 13. A team estimates by discussion, often using planning poker. A reference story is selected, and other stories are judged relative to it. A story estimated at 8 points is not necessarily twice the calendar duration of a 4-point story; the scale is ordinal and team-specific.

Velocity is the number of points completed in a consistent iteration. If a team completed 24, 27, 25 and 28 points in four comparable iterations, the average velocity is:

For 130 remaining points, a simple forecast is approximately:

This assumes stable team capacity, comparable story sizing, sufficiently refined backlog items and no major scope change. A range based on observed velocity is more honest than a single number. Story points are useful for release planning but should not be used to compare the productivity of different teams.

6. COCOMO Concepts

The Constructive Cost Model (COCOMO) is a parametric model family developed by Barry Boehm. It relates software size, typically thousands of delivered source instructions or lines of code (KSLOC), to effort and schedule. COCOMO II includes models for different stages and development contexts.

A simplified form of the basic COCOMO effort equation is:

and schedule may be estimated as:

where E is effort in person-months, T is development time in months, KLOC is thousands of delivered lines of code, and a, b, c and d are calibrated coefficients. Different project modes use different coefficients. The equations are empirical and must not be applied with invented or mismatched coefficients.

COCOMO II may also be expressed conceptually as:

where A is a calibration constant, Size is measured software size, E is an exponent based on scale factors, and EMᵢ are effort multipliers for cost drivers such as reliability, team capability and platform difficulty. The product symbol means that the multipliers are multiplied together.

COCOMO is valuable because it makes cost drivers explicit and supports sensitivity analysis. Its weaknesses include dependence on a credible size estimate, historical calibration and assumptions about the development environment. It should support—not replace—engineering judgment.

7. Three-Point Estimation and Risk

Three-point estimation represents uncertainty with:

• Optimistic estimate, O: favourable but realistic conditions;
• Most likely estimate, M: the mode or best judgment under expected conditions;
• Pessimistic estimate, P: credible adverse conditions, not an impossible disaster.

The triangular expected value is:

The PERT weighted mean is:

PERT gives greater weight to the most likely value and is appropriate when the three estimates describe a roughly unimodal uncertainty distribution. A commonly used approximate variance is:

The standard deviation is the square root of variance. These formulas are approximations; they do not make a subjective estimate statistically precise.

Example. A testing work package has O = 6, M = 10 and P = 18 person-days.

Thus, the approximate standard deviation is 2 person-days. The estimate should be communicated as approximately 9 person-days with meaningful uncertainty, not as a guaranteed nine-day commitment.

For independent work packages, expected efforts may be added. Variances may also be added under the independence assumption. In real software projects, tasks are often correlated, so this assumption must be stated and treated cautiously.

8. Building a Budget and Resource Plan

A resource plan identifies the people, skills, timing and non-human resources needed. A practical plan includes:

A simple resource-loaded budget can be prepared by multiplying each role’s planned effort by its loaded rate, then adding non-labour expenses. The project manager should distinguish baseline budget from approved changes. Actuals should be recorded regularly, including effort consumed, completed scope and remaining estimate.

A useful control measure is the estimate at completion (EAC). In earned value management, one common forecast is:

where AC is actual cost, BAC is budget at completion, EV is earned value and CPI = EV ÷ AC is the cost performance index. This formula assumes current cost efficiency will continue and is meaningful only when earned value is measured consistently. It should not be confused with an initial software-estimation model.

9. Illustrative Case: Community Health Appointment System

Background

A small software company is asked to develop a web application for a community health organisation. The system must allow patients to search available appointments, staff to manage schedules, and administrators to produce reports. It must integrate with an existing identity service and send reminders.

Problem

The client requests completion in four months with a budget of 45,000 currency units. The requirements are incomplete, the organisation has limited integration experience and privacy obligations are significant.

Analysis

The team creates a WBS covering discovery, user-interface design, application services, identity integration, reminders, reporting, testing, security review, deployment, training and project management. It identifies that the client’s deadline is a commitment while the effort remains uncertain.

The team uses three-point estimates for major work packages and compares the total with an analogy from a previous scheduling system. It also uses story points for the evolving backlog. The initial backlog contains 160 points. Recent comparable iterations achieved 22–28 points, giving a provisional delivery range of approximately six to eight iterations rather than a guaranteed date.

A preliminary effort estimate is 42 person-months. The proposed resource plan includes a part-time product analyst, two developers, one tester, shared user-experience support and part-time project management. Security and deployment work are explicitly budgeted rather than treated as free activities.

Approach and solution

The project manager presents three scenarios:

The client selects the minimum viable release for the fixed date and authorises a separate later release. A contingency reserve is governed by change control. The team re-estimates at the end of discovery and every iteration.

Outcome

The first release is delivered with fewer features than the original informal request but meets the agreed acceptance criteria. The organisation receives a transparent budget, a prioritised backlog and a resource forecast for the next release. The project avoids the common failure of promising the full scope without evidence.

Learning points

1. Scope, schedule and budget cannot all be treated as independently fixed.
2. Estimation methods should be combined according to the information available.
3. Testing, privacy, deployment and training must appear in the estimate.
4. Ranges and scenarios help stakeholders make informed trade-offs.
5. Re-estimation is normal professional control, not evidence of incompetence.

10. Challenges, Ethics and Governance

Estimates are vulnerable to optimism bias, strategic misrepresentation, anchoring on a requested price, changing requirements, unavailable specialists, technical debt and hidden integration work. Managers may pressure staff to reduce estimates without reducing scope. This is unethical when uncertainty is concealed from decision-makers.

Professional estimation should:

• disclose assumptions and confidence;
• distinguish known facts from judgment;
• avoid manipulating estimates to win contracts;
• protect staff from unsafe workloads created by unrealistic forecasts;
• include accessibility, security, privacy, legal compliance and quality activities;
• preserve estimation records for audit and learning;
• obtain approval for contingency use and scope changes.

AI-assisted estimation tools can analyse historical repositories, issue trackers and code metrics. They may help identify patterns or omitted tasks, but their outputs depend on data quality and can reproduce historical bias. Sensitive project data must not be uploaded to an unauthorised service. A human must validate the model, explain important assumptions and retain accountability for the decision.

11. Best Practices

1. Establish a common estimation vocabulary and calendar.
2. Maintain a historical database of estimates, actuals and explanations for variance.
3. Estimate by lifecycle activity and work package.
4. Use ranges and confidence levels early in the project.
5. Combine expert judgment with analogy, decomposition or a parametric model.
6. Calibrate function-point productivity, velocity or COCOMO parameters locally.
7. Separate team-relative measures from contractual cost measures.
8. Re-estimate after requirements, architecture, team or technology changes.
9. Review estimates with technical and business stakeholders.
10. Compare forecast effort with remaining work, not merely elapsed time.

Chapter Summary

Effort, duration, cost and capacity are related but distinct concepts. Reliable estimation begins with clear scope, consistent units and explicit assumptions. Expert judgment is valuable but should be structured; analogy uses comparable historical evidence; decomposition exposes work and omissions. Function points provide a technology-independent functional size measure, while story points support relative Agile planning within one team. COCOMO concepts use calibrated size and cost drivers to produce parametric forecasts. Three-point estimation represents uncertainty through optimistic, most likely and pessimistic values, with PERT providing a weighted expected value under stated assumptions.

A professional budget includes labour, non-labour resources and an authorised contingency reserve. A resource plan identifies roles, skills, timing and capacity. Estimates should be revised as evidence improves, and ethical practice requires transparent communication of uncertainty. Models and AI tools can support judgment, but neither removes the need for domain knowledge, governance and accountability.

Key Terms

Effort: Amount of human work required, usually measured in person-hours or person-months.

Duration: Elapsed calendar time required to complete work.

Cost: Monetary value of labour and non-labour resources.

Loaded rate: Labour rate including relevant employment and overhead costs.

Capacity: Work time available from a person or team.

Productivity: Output produced per unit of effort.

Work breakdown structure: Hierarchical decomposition of project scope into manageable work packages.

Expert judgment: Estimate based on specialist knowledge and experience.

Analogical estimation: Forecast based on comparison with completed, similar projects.

Decomposition: Breaking a project or product into smaller estimable components.

Function point: A unit representing delivered user-visible functionality.

UFP: Unadjusted function points before any traditional adjustment factor.

Story point: Team-relative measure of backlog-item size and uncertainty.

Velocity: Story points completed by a team in a consistent iteration.

COCOMO: A family of empirical software cost-estimation models.

KLOC: Thousand delivered lines of code.

Three-point estimation: Use of optimistic, most likely and pessimistic estimates.

Contingency reserve: Authorised allowance for identified uncertainty.

Estimate at completion: Forecast of total project cost based on current performance.

Optimism bias: Systematic tendency to underestimate effort, cost or risk.

Review Questions

Short Answer Questions

1. Distinguish effort from duration.
2. Why should a loaded labour rate be used in a project budget?
3. What are the five traditional function-point categories?
4. Why are story points not directly equivalent to hours?
5. State the PERT expected-value formula and define its variables.

Long Answer Questions

1. Explain how expert judgment, analogy and decomposition can be combined in a professional estimate.
2. Describe the process of preparing a resource-loaded software project budget.
3. Explain the purpose, assumptions and limitations of function-point estimation.
4. Discuss the role and limitations of COCOMO in contemporary software projects.
5. Explain how uncertainty, ethics and governance should influence the presentation of estimates.

Analytical / Application Questions

1. A work package has optimistic, most likely and pessimistic estimates of 8, 14 and 26 person-days. Calculate its PERT expected effort and approximate variance. Explain how you would communicate the result.
2. A team has 150 story points remaining. Its last four comparable velocities were 20, 24, 22 and 26 points per iteration. Estimate the average number of iterations and identify at least two assumptions that could make the forecast unreliable.
3. Design a preliminary estimation approach for a software project with incomplete requirements, a fixed regulatory deadline and an inexperienced team. Justify the methods, reserves and review points you would select.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes effort from duration?

A. Effort is calendar time, while duration is labour cost.

B. Effort is human work, while duration is elapsed calendar time.

C. Effort and duration always have the same numerical value.

D. Duration includes only programming effort.

Correct Answer: B. Effort is human work, while duration is elapsed calendar time.

Question 2

A project uses 20 person-months of effort and a loaded rate of 4,000 currency units per person-month. What is the labour cost?

A. 80 currency units

B. 5,000 currency units

C. 80,000 currency units

D. 800,000 currency units

Correct Answer: C. 80,000 currency units

Question 3

Which estimation method compares a proposed project with completed similar projects?

A. Analogy

B. Velocity tracking

C. Function classification

D. Earned value accounting

Correct Answer: A. Analogy

Question 4

Using the simplified function-point weights in the chapter, what is the contribution of 10 average external outputs?

A. 30 function points

B. 40 function points

C. 50 function points

D. 70 function points

Correct Answer: C. 50 function points

Question 5

A team completed 24, 27, 25 and 28 story points in four comparable iterations. What is its average velocity?

A. 24 points

B. 25 points

C. 26 points

D. 28 points

Correct Answer: C. 26 points

Question 6

Which statement about story points is correct?

A. They are universal measures of staff hours.

B. They are relative, team-specific measures of backlog-item size and uncertainty.

C. They must be identical across all Agile teams.

D. They measure only lines of source code.

Correct Answer: B. They are relative, team-specific measures of backlog-item size and uncertainty.

Question 7

For optimistic 6, most likely 10 and pessimistic 18 person-days, what is the PERT expected effort?

A. 8 person-days

B. 9 person-days

C. 10 person-days

D. 12 person-days

Correct Answer: B. 9 person-days

Question 8

In the simplified COCOMO equation, KLOC refers to:

A. Thousands of delivered lines of code

B. Thousands of calendar months

C. Known labour operating cost

D. Key levels of customer approval

Correct Answer: A. Thousands of delivered lines of code

Question 9

Which item should normally be included in a complete software budget?

A. Only programming salaries

B. Only cloud infrastructure

C. Labour, non-labour costs and an authorised contingency reserve

D. A hidden percentage added without explanation

Correct Answer: C. Labour, non-labour costs and an authorised contingency reserve

Question 10

Why should estimates be revised during a project?

A. Because initial estimates are always deliberately false

B. Because new evidence about scope, performance and risks becomes available

C. Because revision eliminates all uncertainty

D. Because actual effort is irrelevant after planning

Correct Answer: B. Because new evidence about scope, performance and risks becomes available