Estimation & Planning
Estimation is one of the hardest problems in software engineering. Unlike manufacturing, where producing the 1,000th widget takes the same time as the first, software development is fundamentally creative work — every task is different, every codebase has surprises, and every requirement has ambiguity. Yet stakeholders need to know: When will it be done? How much will it cost? What can we deliver by the deadline?
This page covers the most widely used estimation techniques, how to track and use velocity for forecasting, how to plan releases and sprints effectively, and the common cognitive biases that make estimation so difficult.
Why Estimation Is Hard
The Cone of Uncertainty
The Cone of Uncertainty, a concept popularized by Barry Boehm and Steve McConnell, describes how the accuracy of estimates changes over the life of a project. Early in a project, estimates can be off by a factor of 4x in either direction. As the project progresses and unknowns are resolved, the range narrows.
EstimateAccuracy 4x │╲ │ ╲ 2x │ ╲ │ ╲─────────── 1x │──────────────────────────────────── Actual │ ╱─────────── 0.5x │ ╱ │ ╱0.25x │╱ └──────────────────────────────────► Initial Design Build Ship ConceptKey insight: Early estimates are inherently inaccurate. Treating a rough initial estimate as a commitment is a recipe for disappointment. Agile addresses this by re-estimating continuously as more information becomes available, rather than demanding a precise estimate upfront.
Sources of Estimation Error
- Unknown unknowns — Requirements that no one has thought of yet
- Technical uncertainty — Will this library work? How will the system perform at scale?
- Dependency risk — Will the external API be ready? Will the other team deliver their component on time?
- Scope creep — Small additions that individually seem harmless but collectively double the effort
- Human cognitive biases — Anchoring, optimism bias, and planning fallacy (discussed in detail below)
Estimation Techniques
There is no single best estimation technique. Different methods work better for different contexts, team maturity levels, and types of work. The following techniques are listed roughly in order of adoption, from most common to more specialized.
Story Points (Fibonacci Scale)
Story points are the most widely used estimation unit in Agile teams. They represent a relative measure of effort that accounts for complexity, uncertainty, and volume of work. Instead of estimating in absolute time (hours or days), the team compares each story to a reference story.
The Fibonacci scale:
1 - 2 - 3 - 5 - 8 - 13 - 21The non-linear gaps between numbers reflect the reality that larger items carry more uncertainty. It is easy to distinguish between a 1-point and a 2-point story. It is nearly impossible to distinguish between a 14-point and a 15-point story — and the Fibonacci scale does not ask you to try.
How to use story points:
- Choose a reference story — a well-understood, medium-complexity story that the team estimates at 3 or 5 points
- For each new story, compare it to the reference: “Is this story more complex, less complex, or about the same?”
- Assign a Fibonacci number based on relative comparison
- Anything above 13 points should be broken down into smaller stories — large estimates are inherently unreliable
What story points capture:
| Factor | What It Means |
|---|---|
| Complexity | How technically challenging is the work? Does it involve unfamiliar APIs, complex algorithms, or intricate business logic? |
| Effort | How much sheer volume of work is involved? A simple but repetitive task across 20 screens is high effort, low complexity. |
| Uncertainty | How much is unknown? A story involving a third-party integration with poor documentation carries high uncertainty. |
Planning Poker
Planning Poker is a consensus-based estimation technique that prevents anchoring bias — the tendency for one person’s estimate to influence everyone else.
How it works:
- Each team member receives a set of cards with the Fibonacci values (1, 2, 3, 5, 8, 13, 21, plus ”?” for “I need more information” and a coffee cup for “I need a break”)
- The Product Owner reads a user story and provides context
- The team asks clarifying questions
- Each person privately selects a card representing their estimate
- Everyone reveals their cards simultaneously
- If all estimates are the same or close (e.g., all 5s and 8s), the team converges on a value
- If estimates vary significantly (e.g., a 2 and a 13), the highest and lowest estimators explain their reasoning
- The team discusses and re-estimates (usually 1-2 more rounds are sufficient)
Why Planning Poker works:
- Eliminates anchoring — Simultaneous reveal prevents the most senior person’s estimate from influencing others
- Surfaces assumptions — Wide estimate spreads reveal different understandings of the story
- Builds shared understanding — The discussion that follows divergent estimates often clarifies requirements
- Leverages collective wisdom — Research shows that group estimates are more accurate than individual estimates
T-Shirt Sizing
T-shirt sizing uses familiar sizes — XS, S, M, L, XL, XXL — as rough estimate categories. It is particularly useful for early-stage estimation when stories are not yet refined enough for story points.
When to use T-shirt sizing:
- During product discovery or roadmap planning
- When estimating a large backlog of epics or features at a high level
- When the team is new to estimation and needs a gentle starting point
- When precision is less important than relative ordering
Typical mapping (varies by team):
| T-Shirt Size | Relative Effort | Typical Story Points |
|---|---|---|
| XS | Trivial — a few hours of work | 1 |
| S | Small — straightforward, well-understood | 2-3 |
| M | Medium — typical story, some complexity | 5 |
| L | Large — significant complexity or effort | 8 |
| XL | Very large — should probably be broken down | 13 |
| XXL | Epic-sized — must be broken down before work begins | 21+ |
Affinity Estimation
Affinity estimation is a fast technique for estimating a large number of items (e.g., an entire product backlog of 50-100 stories) in a short session.
How it works:
- Write each story on a card or sticky note
- Lay out Fibonacci column headers on a table or wall (1, 2, 3, 5, 8, 13, 21)
- Silently, team members pick up cards one at a time and place them under the column they think is appropriate
- Any team member can move a card they disagree with — but silently
- After all cards are placed and movement has settled, the team discusses any cards that were moved back and forth repeatedly
- Final positions are recorded
Advantages:
- Can estimate 50-100 stories in 1-2 hours
- Reduces “analysis paralysis” that happens with story-by-story estimation
- Silent phase prevents anchoring and groupthink
Ideal Days
Some teams prefer estimating in ideal days — the number of uninterrupted days a story would take if the developer could focus exclusively on it without meetings, context-switching, or interruptions.
Important distinction: An ideal day is not a calendar day. A developer might have 5-6 ideal hours in an 8-hour work day, accounting for meetings, email, and other overhead. An “ideal day” estimate assumes no such overhead.
Advantages:
- Intuitive — most people find it easier to think in time than in abstract points
- Good for teams where work is highly predictable
Disadvantages:
- Invites the “who is doing it?” problem — a task estimated at 2 ideal days by a senior developer might take 5 for a junior developer
- Creates pressure to “finish on time,” which can lead to cutting corners
- Harder to separate from calendar time in stakeholder communication
Velocity: Measuring and Forecasting
What Is Velocity?
Velocity is the total number of story points a team completes per sprint. It is the primary tool for forecasting how much work a team can take on in future sprints.
Example:
| Sprint | Stories Completed | Points Completed |
|---|---|---|
| Sprint 1 | 6 stories | 24 points |
| Sprint 2 | 5 stories | 19 points |
| Sprint 3 | 7 stories | 28 points |
| Sprint 4 | 6 stories | 22 points |
| Sprint 5 | 5 stories | 21 points |
| Average | 5.8 stories | 22.8 points |
How to Calculate Velocity
- At the end of each sprint, count the story points of all stories that meet the Definition of Done
- Partially completed stories contribute zero points — they are not done
- Track velocity over at least 3-5 sprints to establish a reliable average
- Use the average of the last 3-5 sprints as the baseline for forecasting
How to Use Velocity for Forecasting
Once you have a stable velocity, you can forecast delivery dates and sprint capacity.
Sprint planning: Use average velocity to determine how many points of work to pull into the next sprint. If your average velocity is 23 points, plan for approximately 20-25 points.
Release forecasting:
Remaining backlog: 150 story pointsAverage velocity: 23 points/sprintSprint length: 2 weeks
Estimated sprints remaining: 150 / 23 ≈ 7 sprintsEstimated time remaining: 7 x 2 weeks = 14 weeks
Optimistic (using best velocity of 28): 150 / 28 ≈ 6 sprints = 12 weeksPessimistic (using worst velocity of 19): 150 / 19 ≈ 8 sprints = 16 weeks
Delivery range: 12 - 16 weeksAlways provide a range, not a single date. The range communicates the inherent uncertainty in estimation and gives stakeholders realistic expectations.
Velocity Anti-Patterns
- Using velocity to compare teams. Team A’s 40 points and Team B’s 20 points do not mean Team A is twice as productive. Story points are relative to each team’s calibration.
- Using velocity as a performance metric. When velocity becomes a target, teams inflate estimates to appear faster. Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure.”
- Expecting constant velocity. Velocity naturally fluctuates due to holidays, sick days, complex stories, and technical debt. A 10-20% variation is normal.
- Counting partially completed stories. A story that is 90% done contributes 0 points to velocity. It is not done until it meets the Definition of Done.
Release Planning
Release planning bridges the gap between sprint-level work and business-level goals. It answers the question: “Given what we know about our velocity and backlog, when can we deliver this set of features?”
Velocity-Based Release Planning
- Define the release scope — Which Product Backlog items must be included?
- Estimate all items — Every item in the release scope needs a story point estimate
- Calculate the total points — Sum up all estimates
- Divide by average velocity — This gives the number of sprints needed
- Add a buffer — Account for estimation error, scope growth, and unexpected work (typically 20-30%)
Example:
Release scope: 200 story pointsAverage velocity: 25 points/sprintSprints needed: 200 / 25 = 8 sprintsBuffer (25%): 8 x 1.25 = 10 sprintsSprint length: 2 weeks
Target release: 10 x 2 = 20 weeks from nowThe Now-Next-Later Roadmap
Traditional roadmaps with fixed dates and detailed feature lists create the illusion of certainty. The Now-Next-Later format acknowledges the Cone of Uncertainty by varying the level of detail based on time horizon.
┌──────────────────────────────────────────────────────────┐│ PRODUCT ROADMAP │├──────────────┬──────────────────┬─────────────────────────┤│ NOW │ NEXT │ LATER ││ (Current │ (Next 1-2 │ (3+ quarters) ││ quarter) │ quarters) │ ││ │ │ ││ ✓ Detailed │ ○ Themes & │ ◇ Strategic goals & ││ stories │ high-level │ broad directions ││ │ features │ ││ ✓ Estimated │ ○ Rough │ ◇ Not estimated ││ & planned │ estimates │ ││ │ │ ││ ✓ Committed │ ○ Likely but │ ◇ Aspirational ││ │ negotiable │ │├──────────────┼──────────────────┼─────────────────────────┤│ - User auth │ - Mobile app │ - International ││ - Dashboard │ - Reporting │ expansion ││ - API v2 │ - SSO │ - AI recommendations ││ - Search │ - Webhooks │ - Marketplace │└──────────────┴──────────────────┴─────────────────────────┘Advantages of Now-Next-Later:
- Reflects reality — near-term plans are more certain than long-term plans
- Avoids false precision — no specific dates on items that are months away
- Encourages conversation — stakeholders can see the direction without treating it as a contract
- Easy to update — items flow from Later to Next to Now as they are refined
Sprint Planning: Capacity Planning
Sprint Planning is not just about pulling items from the backlog until you hit the velocity target. Effective sprint planning accounts for the team’s actual capacity in the upcoming sprint.
Calculating Sprint Capacity
- Count available days per person — Subtract vacations, holidays, training days, and planned meetings
- Apply a focus factor — Not every hour of a work day is productive development time. A typical focus factor is 60-70% (accounting for meetings, email, code reviews, and other overhead)
- Calculate team capacity — Sum the available productive hours across all team members
- Compare to velocity — If the team is at reduced capacity (e.g., two people are on vacation), reduce the sprint commitment proportionally
Example:
Team: 5 developers, 2-week sprint (10 working days each)
Developer A: 10 days available x 6 productive hours = 60 hoursDeveloper B: 10 days available x 6 productive hours = 60 hoursDeveloper C: 8 days available x 6 productive hours = 48 hours (2 days PTO)Developer D: 10 days available x 6 productive hours = 60 hoursDeveloper E: 9 days available x 6 productive hours = 54 hours (1 day training)
Total capacity: 282 productive hoursNormal capacity: 300 productive hours (all 5 at 10 days)Capacity ratio: 282 / 300 = 94%
Average velocity: 25 pointsAdjusted target: 25 x 0.94 ≈ 23-24 pointsCommon Estimation Pitfalls
Understanding cognitive biases that affect estimation is the first step toward countering them.
Anchoring Bias
What it is: The tendency to rely too heavily on the first piece of information encountered (the “anchor”) when making decisions.
How it affects estimation: If the first person to speak says “this looks like a 3-pointer,” everyone else’s estimate is unconsciously pulled toward 3. Even if the true estimate is 8, people will adjust insufficiently from the anchor.
Countermeasure: Use Planning Poker with simultaneous reveal. Never estimate sequentially.
Planning Fallacy
What it is: The tendency to underestimate the time, costs, and risks of future actions while overestimating their benefits. First described by Daniel Kahneman and Amos Tversky.
How it affects estimation: Teams consistently estimate how long tasks should take in an ideal scenario, ignoring historical evidence of how long similar tasks actually took.
Countermeasure: Use reference class forecasting — look at how long similar tasks took in the past and use that as the baseline, not your optimistic projection.
Optimism Bias
What it is: The tendency to believe that you are less likely to experience negative events than others. “Bugs and delays happen to other teams, not ours.”
How it affects estimation: Teams underestimate the likelihood of encountering problems, dependencies, and rework.
Countermeasure: Apply a buffer to estimates (20-30% for well-understood work, 50%+ for novel work). Track actual vs. estimated effort to calibrate over time.
Hofstadter’s Law
“It always takes longer than you expect, even when you take into account Hofstadter’s Law.” — Douglas Hofstadter
This recursive observation captures the fundamental challenge of estimation: even when you know you are likely to underestimate, you still underestimate. The law is a reminder to be humble about estimation accuracy and to build in margin.
Parkinson’s Law
“Work expands to fill the time available for its completion.” — C. Northcote Parkinson
If you estimate a task at 5 days and it could be done in 3, it will take 5 days because the extra time gets absorbed by perfectionism, scope expansion, or reduced urgency. This is one reason why Agile favors small stories with tight timeframes — less room for work to expand.
The Student Syndrome
The tendency to start working on a task only as the deadline approaches, regardless of how much time was allocated. Even if a developer has 10 days for a 5-day task, work often does not begin in earnest until day 5 or 6.
Countermeasure: Small stories, WIP limits, and daily standups create visibility and gentle accountability that reduce this tendency.
The #NoEstimates Movement
The #NoEstimates movement, championed by practitioners like Woody Zuill and Vasco Duarte, questions whether detailed estimation is worth the effort. The core argument is not that teams should never think about size and effort, but that traditional estimation practices often consume significant time while providing little predictive value.
Key Arguments
- Estimation time is waste — Hours spent in estimation meetings could be spent delivering working software
- Estimates are often wrong — Despite the effort invested, estimates frequently miss the mark
- Alternatives exist — Throughput-based forecasting (how many items per week) can be as accurate as point-based forecasting with far less overhead
- Small stories reduce the need for estimation — If every story is roughly the same small size, counting stories is sufficient for forecasting
Throughput-Based Forecasting
Instead of estimating each story in points, the team:
- Breaks all work into similarly-sized small stories
- Counts the number of stories completed per sprint (throughput)
- Forecasts delivery based on throughput: “We have 30 stories remaining. We complete about 6 per sprint. That is approximately 5 sprints.”
This approach works best when:
- The team is disciplined about breaking stories to a consistent size
- The work is relatively homogeneous (similar types of tasks)
- The team has historical throughput data
When #NoEstimates Does Not Work
- Stakeholders require cost and timeline commitments for budgeting or contracts
- Stories vary wildly in size and cannot be easily standardized
- The team is new and has no throughput data to draw from
- Cross-team dependencies require coordinated planning
Estimation Techniques Comparison
| Technique | Speed | Accuracy | Best For | Drawbacks |
|---|---|---|---|---|
| Story Points (Fibonacci) | Moderate | Good (with practice) | Sprint planning, release forecasting | Requires calibration, can be gamed |
| Planning Poker | Slow (per story) | High | Individual story estimation with team consensus | Time-consuming for large backlogs |
| T-Shirt Sizing | Fast | Low-moderate | Early-stage roadmap planning, large backlogs | Too coarse for sprint planning |
| Affinity Estimation | Very fast | Moderate | Estimating 50-100 items in bulk | Less accurate for individual items |
| Ideal Days | Moderate | Moderate | Teams new to estimation | Confused with calendar days, varies by person |
| Throughput Forecasting | Very fast | Moderate-good | Teams with consistent story sizes | Requires disciplined story splitting |
Key Takeaways
-
All estimates are wrong; some are useful. The goal of estimation is not precision — it is to provide enough information for informed decision-making. A range is always more honest than a point estimate.
-
Relative estimation beats absolute estimation. Comparing stories to each other (“this is about twice as hard as that reference story”) is far more reliable than estimating in hours or days.
-
Velocity is a forecasting tool, not a performance metric. The moment velocity becomes a target, teams game it by inflating estimates, and it loses its predictive value.
-
Small stories improve everything. Estimation accuracy, flow, throughput, testing, code review — everything gets better when stories are small. If you only adopt one practice from this page, make it “break stories down until they are small.”
-
Account for cognitive biases. Anchoring, optimism bias, and planning fallacy are real and measurable. Use techniques like Planning Poker (simultaneous reveal) and reference class forecasting (historical data) to counteract them.
-
The Cone of Uncertainty narrows over time. Early estimates should be treated as rough ranges. As the team learns more about the work, estimates become more accurate. Re-estimate as you go, rather than committing to early numbers.
-
Choose the right technique for the context. Planning Poker for refined stories in sprint planning. T-shirt sizing for roadmap discussions. Affinity estimation for backlog grooming sessions. No single technique works for every situation.