Software Estimation Techniques Cheat Sheet

Updated 2026-05-28

🧠Study flashcards on this topic76 cards · spaced repetition→

Software estimation is the practice of predicting the effort, time, cost, and resources required to complete a software project or task. It sits at the crossroads of project management, engineering judgment, and empirical data analysis. Estimation matters because delivering value requires planning under uncertainty — teams need to answer "how long?" and "how much?" to commit to work, forecast delivery, and allocate resources. The core challenge is that estimation is fundamentally a prediction problem in an environment where requirements evolve, complexity accumulates, and human judgment is subject to systematic bias. The single most important insight: estimates are not commitments — they are probabilistic forecasts that should improve through learning and feedback, and the best techniques embrace relative comparison over illusory precision.

What This Cheat Sheet Covers

This topic spans 11 focused tables and 83 indexed concepts, 76 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Relative Estimation ScalesTable 2: Absolute Estimation & Order-of-MagnitudeTable 3: Consensus-Based Estimation MethodsTable 4: Analytical & Parametric ModelsTable 5: Three-Point EstimationTable 6: Velocity & ForecastingTable 7: Reference Points & FrameworksTable 8: Cognitive Biases Affecting EstimationTable 9: Estimation Anti-PatternsTable 10: Alternative & Advanced ApproachesTable 11: Estimation Maturity & Practices

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Relative Estimation Scales

Relative scales replace absolute time estimates with dimensionless numbers or labels, letting teams judge complexity by comparison rather than by prediction. The Fibonacci sequence dominates because its exponentially widening gaps naturally signal the growing uncertainty of larger items — a property that linear scales lack.

Scale	Example	Description
Story Points (Fibonacci)	123581321	• Most popular relative scale • modified Fibonacci sequence where gaps increase with size, reflecting growing uncertainty for larger items • teams compare work items against reference stories rather than estimating absolute hours.
T-Shirt Sizing	`XS, S, M, L, XL, XXL`	• Lightweight sizing using familiar clothing sizes • ideal for early-stage roadmaps, portfolios, or large backlogs where precision isn't needed yet • easy for non-technical stakeholders to understand.
Story Points (Modified Fibonacci)	12358132040100	• Adds larger values (20, 40, 100) for epic-level work • commonly used in SAFe and scaled agile environments • a value of 100 signals the item needs decomposition before estimation.
Powers of 2	12481632	• Exponential scale emphasizing doubling complexity • eliminates pointless debate between adjacent values (e.g., 6 vs. 7) • less common than Fibonacci but mathematically elegant for uncertainty representation.
Linear Scale	12345678910	• Simple numeric scale with equal intervals • treats complexity as linear • generally discouraged in agile because it implies false precision and doesn't account for exponential uncertainty growth.
Dog Breeds	`Chihuahua, Poodle, Labrador, Great Dane`	• Alternative metaphor for sizing where breed implies relative size • used occasionally to break monotony or engage teams differently • functionally equivalent to T-shirt sizing but non-standard.

Table 2: Absolute Estimation & Order-of-Magnitude

Some contexts demand concrete time or effort units — stakeholder contracts, parametric models, and feasibility checks all rely on absolute quantities rather than relative points. Communicating the precision class of any absolute estimate (ROM, ballpark, definitive) is as important as the number itself, because the implied accuracy range varies dramatically by how much scope is known.

Unit	Example	Description
Rough Order of Magnitude (ROM)	`$375K–$875K (based on $500K mid-point, –25%/+75%)`	• Widest accuracy class used during project initiation when scope is less than 5% defined • PMI standard range: –25% to +75%; AACE Class 5 range: –50% to +100% • always presented as a range, not a single figure; replaced by more precise estimates as scope firms up.

The rest of this section is part of the full cheat sheet

Table 3: Consensus-Based Estimation Methods

Structured group discussion turns estimation into a collaborative learning exercise rather than a solo prediction. The best consensus techniques control for anchoring and dominance bias by separating the thinking phase from the reveal phase, forcing each participant to commit independently before group discussion begins.

Technique	Example	Description
Planning Poker	Team reveals cards simultaneously: `3, 5, 5, 8` then discusses outliers	• Most widely adopted technique • each member privately selects estimate, all reveal at once, outliers explain reasoning, team converges through discussion • simultaneous reveal prevents anchoring bias.

The rest of this section is part of the full cheat sheet

Table 4: Analytical & Parametric Models

Formal, model-driven estimation uses historical data and mathematical relationships to produce effort forecasts from measurable inputs like size, complexity, and team capability. These models are most accurate when calibrated against real organizational data; using published industry defaults without calibration often yields wide error margins.

Model	Example	Description
COCOMO (Constructive Cost Model)	$\text{Effort} = a \times (\text{KLOC})^b \times EAF$	• Classic parametric model estimating effort from lines of code and cost drivers • three levels (Basic, Intermediate, Detailed) • established 1981; still influential • requires historical data calibration for accuracy.

The rest of this section is part of the full cheat sheet

Table 1: Relative Estimation Scales

Scale	Example	Description
Story Points (Fibonacci)	123581321	• Most popular relative scale • modified Fibonacci sequence where gaps increase with size, reflecting growing uncertainty for larger items • teams compare work items against reference stories rather than estimating absolute hours.
T-Shirt Sizing	`XS, S, M, L, XL, XXL`	• Lightweight sizing using familiar clothing sizes • ideal for early-stage roadmaps, portfolios, or large backlogs where precision isn't needed yet • easy for non-technical stakeholders to understand.
Story Points (Modified Fibonacci)	12358132040100	• Adds larger values (20, 40, 100) for epic-level work • commonly used in SAFe and scaled agile environments • a value of 100 signals the item needs decomposition before estimation.
Powers of 2	12481632	• Exponential scale emphasizing doubling complexity • eliminates pointless debate between adjacent values (e.g., 6 vs. 7) • less common than Fibonacci but mathematically elegant for uncertainty representation.
Linear Scale	12345678910	• Simple numeric scale with equal intervals • treats complexity as linear • generally discouraged in agile because it implies false precision and doesn't account for exponential uncertainty growth.
Dog Breeds	`Chihuahua, Poodle, Labrador, Great Dane`	• Alternative metaphor for sizing where breed implies relative size • used occasionally to break monotony or engage teams differently • functionally equivalent to T-shirt sizing but non-standard.

Table 2: Absolute Estimation & Order-of-Magnitude

Unit	Example	Description
Rough Order of Magnitude (ROM)	`$375K–$875K (based on $500K mid-point, –25%/+75%)`	• Widest accuracy class used during project initiation when scope is less than 5% defined • PMI standard range: –25% to +75%; AACE Class 5 range: –50% to +100% • always presented as a range, not a single figure; replaced by more precise estimates as scope firms up.

Table 3: Consensus-Based Estimation Methods

Technique	Example	Description
Planning Poker	Team reveals cards simultaneously: `3, 5, 5, 8` then discusses outliers	• Most widely adopted technique • each member privately selects estimate, all reveal at once, outliers explain reasoning, team converges through discussion • simultaneous reveal prevents anchoring bias.

Table 4: Analytical & Parametric Models

Model	Example	Description
COCOMO (Constructive Cost Model)	$\text{Effort} = a \times (\text{KLOC})^b \times EAF$	• Classic parametric model estimating effort from lines of code and cost drivers • three levels (Basic, Intermediate, Detailed) • established 1981; still influential • requires historical data calibration for accuracy.