Software Estimation and Planning

Software estimation and planning predict the effort, cost, schedule, and resources a software project will require and organize the work to deliver it within those constraints.

Definition

Software estimation is the prediction of the effort, duration, and cost needed to develop or maintain software, and planning is the organization of activities, milestones, and resources to achieve project objectives within those estimates.

Scope

This topic covers size measures such as lines of code and function points; algorithmic cost models such as COCOMO; expert-judgment, analogy, and planning-poker estimation; work breakdown and scheduling techniques including critical path and burndown; agile planning with velocity and story points; and the treatment of estimation uncertainty through ranges and the cone of uncertainty.

Core questions

• How is the size of software measured to drive estimates?
• How do algorithmic, analogy, and expert-judgment methods compare?
• How is uncertainty represented and reduced as a project progresses?
• How does agile planning with velocity differ from up-front scheduling?

Key theories

Algorithmic cost models

Models such as COCOMO express effort and schedule as calibrated functions of estimated size and project cost drivers, giving repeatable estimates that can be tuned with historical data.

Function point sizing

Function point analysis sizes software by counting and weighting its functional components independently of implementation language, providing a technology-neutral size input for estimation.

Clinical relevance

Realistic estimation and planning underpin commitments to stakeholders and resource decisions; chronic underestimation drives the schedule and budget overruns that plague software projects, so disciplined methods and explicit uncertainty are essential.

Evidence & guidelines

Empirical research on estimation accuracy and models such as COCOMO II provide evidence-based guidance, and function point counting is governed by IFPUG and ISO/IEC functional size measurement standards.

History

Function points were introduced by Albrecht in the late 1970s and COCOMO by Boehm in 1981, giving estimation a quantitative footing; subsequent work refined models (COCOMO II), studied estimation bias, and introduced lightweight relative-sizing methods for agile planning.

Debates

Estimation versus the no-estimates movement

Some agile practitioners argue that detailed estimation wastes effort and that small, steady delivery makes forecasts more reliable than estimates, while others maintain that estimates remain necessary for planning and commitment; the debate turns on context and stakeholder needs.

Key figures

• Barry Boehm
• Allan Albrecht
• Steve McConnell

Seminal works

• boehm1981
• albrecht1983
• mcconnell2006

Frequently asked questions

Why are software estimates so often wrong?

Estimates are made when least is known, requirements change, and human bias tends toward optimism; the cone of uncertainty captures how wide early estimates inevitably are, which is why ranges and re-estimation are preferred over single fixed numbers.

Are story points just disguised hours?

No. Story points express relative size and complexity rather than absolute time; combined with a team's observed velocity they yield forecasts, but equating one point to a fixed number of hours undermines their purpose of capturing relative effort.