Agile Estimation, Forecasting and Release Planning

Introduction

Agile teams estimate and forecast in order to support decisions, not to create an illusion of certainty. A product owner may need to decide which capabilities can be included in a release, a customer may need an indicative delivery window, and a team may need to coordinate dependencies. These decisions require useful information about relative size, capacity, historical delivery and uncertainty.

Agile estimation differs from traditional detailed planning. Traditional approaches often attempt to predict the duration and cost of every task before development begins. Agile approaches accept that requirements, technology and stakeholder understanding will change. Estimation is therefore progressive: broad and uncertain early estimates are refined as knowledge increases.

The central principle is that an estimate is a reasoned forecast under stated assumptions. It is not a promise. A responsible forecast communicates both a likely outcome and the uncertainty surrounding it.

Learning Objectives

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

• explain relative estimation and story points;
• facilitate Planning Poker effectively;
• distinguish effort, duration, capacity and velocity;
• calculate and interpret team velocity;
• produce a simple release forecast using historical data;
• recognize uncertainty, variability and the danger of false precision;
• apply estimation and forecasting responsibly in a practical project context.

1. Estimation as a Decision-Support Activity

An estimate is an assessment of the size, effort or complexity of work. A forecast is a projection of what may happen, based on available evidence. A commitment is a decision to pursue a result under agreed conditions. These terms should not be treated as synonyms.

Agile estimation commonly considers three dimensions:

1. Effort: the amount of work required.
2. Complexity: the difficulty of the work, including technical uncertainty.
3. Risk and uncertainty: the possibility that assumptions will prove incorrect.

Story points normally combine these dimensions into a relative measure. They do not represent hours. A five-point item is generally understood to be larger than a three-point item, but not necessarily 66.7% more work in any objective sense.

Estimation should be performed at the level appropriate to the decision. A product roadmap may use themes or broad capabilities; a release forecast may use product backlog items; sprint planning may use tasks and team capacity. Excessive detail too early creates administrative effort while requirements are still unstable.

Important terminology

2. Relative Estimation and Story Points

Relative estimation compares work items with one another rather than assigning each an absolute duration. The team first selects a reference item that is sufficiently understood and assigns it a small value, such as two or three points. Other items are then compared with that reference.

A team may consider:

• the amount of functionality;
• the number of technical components affected;
• integration and data concerns;
• testing effort;
• uncertainty and the likelihood of discovery work;
• operational, security or compliance complexity.

A commonly used scale is a modified Fibonacci sequence: 1, 2, 3, 5, 8, 13 and 20. The increasing gaps reflect reduced precision for larger and less certain items. Some teams use T-shirt sizes such as XS, S, M, L and XL before converting them to points.

Story points are useful only when the team uses them consistently. A point value has no universal meaning across teams. If Team A estimates a story at eight points and Team B estimates another story at eight points, their work is not necessarily comparable. Velocity is also meaningful primarily within the team and its stable working conditions.

What story points are not

Story points are not:

• person-hours;
• individual performance measures;
• a basis for comparing teams;
• a contractual guarantee;
• a measure of business value;
• a reason to reward teams for increasing point totals.

Converting points directly into hours is especially misleading. If a team says that one point equals four hours, it has replaced relative estimation with an unreliable time conversion. Different items with the same point value may require different elapsed times because of interruptions, dependencies or waiting for external decisions.

3. Planning Poker

Planning Poker is a structured consensus technique. Each participant privately selects a card representing the relative size of an item. Cards are revealed simultaneously, reducing the influence of the first estimate stated aloud.

A typical procedure is:

1. The product owner explains the item and its acceptance criteria.
2. Participants ask clarifying questions.
3. The team identifies assumptions, dependencies and unknowns.
4. Each estimator privately selects a card.
5. Cards are revealed together.
6. The highest and lowest estimators explain their reasoning.
7. The team discusses the evidence rather than defending personal authority.
8. The group re-estimates if necessary and records the agreed value.

Planning Poker is not a vote in which the majority automatically wins. Its value lies in exposing different mental models. A low estimate may indicate that one participant knows of a reusable component; a high estimate may reveal a security, data migration or integration concern that others overlooked.

The facilitator should prevent anchoring, dominant behaviour and false consensus. The product owner clarifies value and behaviour but should not pressure the developers toward a preferred number. If uncertainty is extreme, the correct response may be to split the item, conduct a time-boxed spike or estimate it at a larger size until it is refined.

4. Splitting Work Before Estimating

Large items produce unreliable estimates because they contain multiple user outcomes and unknowns. Splitting should preserve value where possible. Useful approaches include splitting by:

• user workflow step;
• business rule;
• data variation;
• simple versus advanced behaviour;
• happy path versus exception path;
• read capability versus update capability;
• platform or interface, when independent delivery is possible.

A technical task list is not automatically a set of valuable backlog items. For example, “build database,” “write API” and “create screen” may be necessary tasks, but they do not independently demonstrate a user outcome. Vertical slicing aims to deliver a thin, testable increment across the relevant layers.

If an item is estimated at 13 points or more, the team should ask whether it can be split or whether a discovery activity is required. The threshold is a heuristic, not a law. A team may use a different threshold based on its product and iteration length.

5. Velocity and Its Responsible Use

Velocity is the sum of the estimates of items that satisfy the Definition of Done during an iteration. If completed items have estimates of 3, 5 and 8 points, the iteration velocity is 16 points.

Only completed work should count. Partially completed items generally contribute zero to velocity because they have not yet produced a finished increment. Counting partial points creates incentives to report progress that cannot be released or verified.

For a stable team, a simple average velocity over the last n iterations is:

Here, Vᵢ is the velocity in iteration i, n is the number of iterations, and V̄ is the arithmetic mean velocity in story points per iteration. The formula assumes that the team, iteration length, estimation scale and Definition of Done are reasonably stable.

Example: suppose the last five velocities are 18, 22, 20, 16 and 24 points. Then:

The average describes past performance; it does not guarantee future performance. A range may communicate uncertainty better. In this example, the observed range is 16–24 points per iteration. A forecast based on 20 points should not be presented as certain if the team is changing, the product contains major unknowns or external dependencies are unresolved.

Velocity should support planning, not ranking. Comparing velocities across teams is invalid unless estimation practices, product context, team composition and working conditions are equivalent—which is rarely true. Using velocity as a target often causes inflation of estimates, splitting games or reduced attention to quality.

6. Capacity Planning

Velocity is historical delivery; capacity is the expected availability of people in a future iteration. Capacity considers working days, leave, public holidays, training, support duties and the proportion of time available for the product. It is not the same as maximum theoretical hours.

A simple capacity calculation is:

where C is total available team capacity in person-hours, dⱼ is the number of available working days for person j, hⱼ is the nominal working hours per day, and aⱼ is the fraction of time available for planned product work, with 0 ≤ aⱼ ≤ 1. The calculation assumes that hours are a useful approximation and that the availability assumptions are known.

For example, three developers each have ten working days and eight nominal hours per day. One is available at 75%, one at 100% and one at 50% for planned work:

This does not mean that 180 hours of story work can reliably be promised. Collaboration, defects, interruptions and coordination reduce effective delivery. Capacity is most useful for identifying unusual conditions, such as a holiday period or a partially staffed iteration.

Teams may combine capacity and velocity cautiously. If historical velocity was achieved with approximately 200 available person-hours and the next iteration has 160 hours, the team should expect lower delivery, but a direct proportional conversion from hours to points is only a rough heuristic. It should not be treated as a scientific law because productivity is not linear and work items differ.

7. Release Forecasting

A release forecast begins with a product goal, a selected set of backlog items and evidence about delivery. It should state assumptions, confidence and the possibility of change.

If the remaining backlog is S story points and the expected velocity is V, a basic iteration estimate is:

where I is the estimated number of iterations. Because iterations are discrete, a practical planning value is usually rounded upward. If 80 points remain and expected velocity is 20 points per iteration, the central forecast is four iterations. If iterations are two weeks, the central calendar estimate is eight iteration-weeks, or approximately eight weeks, excluding release preparation and other time not represented in the iteration plan.

The calculation assumes stable scope, comparable estimation, a reasonably stable team and no major blocked work. These assumptions should always be made explicit.

A range is more honest than a single date. If recent velocity has ranged from 16 to 24 points, then 80 points would require approximately:

at the high-delivery end and:

at the low-delivery end. Since partial iterations cannot normally complete the whole release, the practical range is approximately four to five iterations, subject to scope and dependency assumptions. This is a simple scenario range, not a probability distribution.

Confidence and forecast language

Good forecast language distinguishes levels of confidence:

• Central scenario: the outcome suggested by the most representative historical evidence.
• Optimistic scenario: assumes favourable delivery conditions and limited disruption.
• Conservative scenario: allows for lower velocity, discovery and interruptions.
• Commitment: a management decision that may involve trade-offs, not a statistical certainty.

When sufficient historical data exists, teams may use Monte Carlo forecasting based on throughput or cycle time. Such methods repeatedly sample historical delivery patterns to estimate a range of completion dates. They are useful only when the data reflects the future system. A model trained on a stable team cannot automatically forecast a newly formed team, a major architecture change or a different work type.

8. Scope, Schedule and Uncertainty

Release planning involves a relationship among scope, time, capacity and quality. If the date is fixed, scope should remain negotiable where possible. If scope is fixed, the date may need to move. Quality should not be treated as the variable that absorbs all uncertainty; reducing testing or acceptance standards creates future cost and operational risk.

A useful release plan identifies:

• the minimum valuable product or release goal;
• must-have and optional items;
• technical and organisational dependencies;
• assumptions and risks;
• acceptance and operational readiness conditions;
• a review point at which the forecast will be updated.

Forecasts should be updated as evidence changes. Re-estimation is not failure. A changed forecast may reflect new requirements, improved understanding, staff absence, defects or an external dependency. Concealing such changes produces a more attractive document but a less reliable decision.

Avoiding false precision

False precision occurs when uncertain information is expressed with unjustified exactness, such as “the release will complete on 14 September at 10:00” when the backlog is still changing. Precision should match evidence.

Practices that reduce false precision include:

• using ranges rather than single-point dates;
• reporting assumptions beside the forecast;
• showing historical variation;
• distinguishing completed work from partially started work;
• revisiting estimates after discovery;
• using confidence language understood by stakeholders;
• avoiding decimal story points and unnecessary conversion to hours.

9. Worked Release-Planning Example

A small team has a product backlog containing 96 estimated points. The last six iterations produced velocities of 18, 21, 19, 24, 20 and 22 points.

The mean velocity is:

The observed range is 18–24 points. Using the mean, the central forecast is:

The team should therefore plan approximately five iterations in the central scenario. Using the observed range gives a rough scenario interval:

• at 24 points per iteration: 96 ÷ 24 = 4 iterations;
• at 18 points per iteration: 96 ÷ 18 ≈ 5.33, requiring approximately six complete iterations.

Thus, a responsible communication might be: “The current scope is forecast at about five iterations, with a simple historical range of approximately four to six iterations. This assumes the team remains stable, no major scope is added, and the release definition remains unchanged.”

If the team has a two-week iteration, the central forecast is about ten weeks. The calendar forecast must still allow for release hardening, security review, deployment approval, training or operational preparation if these are not included in the estimated backlog.

10. Applied Case: Northstar Service Portal

Background

The following is a fictional illustrative case. Northstar Services is replacing an email-based customer support process with a self-service portal. The organisation wants a usable first release before its annual renewal period.

Problem

Stakeholders initially requested 140 story points for the release. The team had completed only two iterations, with velocities of 17 and 23 points. Several items involved an untested identity-management integration. A senior manager asked for a precise launch date based on “20 points per sprint.”

Analysis

The team identified three problems. First, the average of two iterations was weak evidence. Second, the 140 points included optional reporting and administrative features. Third, the identity integration could create substantial variation. The team refined the release goal into a minimum usable portal: search common answers, submit a request, view request status and receive notifications.

The revised minimum scope was 78 points. The team split large items, created a time-boxed technical spike for identity integration and clarified the Definition of Done to include automated tests, accessibility checks and deployment documentation.

After four further iterations, velocities were 19, 21, 18 and 23 points. Together with the earlier values, the six-iteration range was 17–23 points, and the mean was:

The central forecast for 78 points was approximately four iterations, while the scenario range based on the observed limits was approximately four to five iterations. The team also identified two weeks of operational preparation outside the development iterations.

Approach and outcome

The product owner removed low-value reporting from the first release and retained a clear ordering of the remaining backlog. The release communication stated a forecast of four iterations for the product scope, with a conservative expectation of five if the identity integration or external approval caused disruption, followed by operational preparation.

The portal was released within the conservative window. The most important success was not the numerical accuracy of the original estimates; it was the transparent relationship among scope, evidence, uncertainty and decision-making.

Learning points

• A smaller, valuable scope is easier to forecast than a broad wish list.
• A forecast becomes stronger as more comparable delivery evidence accumulates.
• Technical spikes can reduce uncertainty without pretending to estimate unknown work precisely.
• External dependencies must be visible in the plan.
• A range and assumptions are more useful than an exact unsupported date.

11. Governance, Ethics and Contemporary Tools

Estimation has ethical implications because forecasts influence budgets, employment expectations and customer commitments. Managers should not pressure teams to lower estimates, hide uncertainty or inflate velocity. Estimates should not be used to rank individuals. A psychologically safe team is more likely to report risks accurately.

Digital planning tools can calculate velocity, display burn-up charts and generate forecasts. Artificial intelligence may assist by identifying similar historical items, detecting unusually large stories or summarising assumptions. However, AI-generated estimates are not objective facts. They may reproduce biased historical data, overlook tacit knowledge, or encourage false confidence. Human review, traceable assumptions and data privacy remain necessary.

A burn-up chart can communicate completed scope and total scope over time, while a burn-down chart shows remaining estimated work. Both can mislead if scope changes are hidden or if teams manipulate estimates. Metrics should therefore be interpreted with qualitative information about quality, value, blocked work and customer outcomes.

12. Best-Practice Checklist

Before accepting a release forecast, ask:

1. Is the release goal clear?
2. Are backlog items sufficiently understood and vertically sliced?
3. Is the estimation scale used consistently by this team?
4. Are estimates relative rather than disguised hours?
5. Does the Definition of Done remain stable?
6. Is velocity based only on completed work?
7. Have team capacity and absences been considered?
8. Are dependencies, spikes and operational work visible?
9. Is a range presented alongside the central scenario?
10. Are assumptions and confidence clearly communicated?
11. Will the forecast be updated when evidence changes?
12. Are metrics being used for learning rather than punishment?

Chapter Summary

Agile estimation is a collaborative, relative and revisable activity. Story points express comparative size, complexity and uncertainty; they are not hours or performance scores. Planning Poker helps teams expose different assumptions and reduce anchoring. Velocity describes completed estimated work in past iterations, whereas capacity describes expected availability in a future iteration. A release forecast can relate remaining scope to historical velocity, but the result depends on assumptions about team stability, scope, quality and dependencies. Ranges, scenarios and explicit confidence are preferable to false precision. Responsible release planning also involves slicing valuable work, protecting quality, updating forecasts and using metrics ethically.

Key Terms

Story point: A relative measure of backlog-item size, complexity and uncertainty.

Relative estimation: Estimating work by comparison with reference items.

Planning Poker: A facilitated, simultaneous estimation technique using numbered cards.

Velocity: Completed estimated work in a defined iteration.

Capacity: Available working time or effort for planned work.

Forecast: A projection based on evidence and stated assumptions.

Release: A delivery of product functionality to users or an operational environment.

Backlog refinement: Collaborative clarification and preparation of backlog items.

Definition of Done: Shared conditions that must be satisfied for work to be complete.

Vertical slice: A thin increment that delivers a usable outcome across necessary layers.

Spike: A time-boxed investigation used to reduce uncertainty.

Throughput: Number of work items completed in a period.

Cycle time: Elapsed time from starting an item to completing it.

Scope: The set of work or outcomes included in a plan.

Uncertainty: Lack of complete knowledge about future conditions or effort.

False precision: Unsupported exactness in an estimate or forecast.

Release forecast: Projection of when a defined release scope may be completed.

Monte Carlo forecasting: Probabilistic forecasting based on repeated sampling of historical delivery data.

Review Questions

Short Answer Questions

1. What is the difference between a story point and an hour estimate?
2. Why should partially completed backlog items normally contribute zero to velocity?
3. State two factors that may reduce team capacity in a future iteration.
4. What is the purpose of revealing high and low Planning Poker estimates?
5. Why is a forecast range generally more responsible than a single exact date?

Long Answer Questions

1. Explain the purpose, procedure and limitations of Planning Poker.
2. Discuss how velocity should and should not be used in Agile management.
3. Explain the relationship between capacity, velocity and release forecasting.
4. Describe how a team can split a large backlog item into valuable vertical slices.
5. Evaluate the ethical risks of using estimates and velocity as management performance targets.

Analytical / Application Questions

1. A team’s last five velocities are 14, 18, 16, 20 and 12 points. Calculate the mean velocity and state a reasonable limitation of using it for a release forecast.
2. A backlog contains 72 points and the team’s historical velocity ranges from 15 to 21 points per iteration. Produce a simple scenario range for the number of iterations and explain why it is not a guarantee.
3. A release has a fixed date, but its backlog contains essential, desirable and experimental features. Propose a planning approach that manages scope, uncertainty and quality without reducing the Definition of Done.

Multiple Choice Questions with Answers

Question 1

What do story points primarily represent?

A. Exact person-hours required

B. Relative size, complexity and uncertainty

C. Individual developer productivity

D. Business value alone

Correct Answer: B. Relative size, complexity and uncertainty

Question 2

Which work normally contributes to iteration velocity?

A. All started work

B. Work estimated during refinement

C. Items satisfying the Definition of Done

D. Tasks assigned to senior developers

Correct Answer: C. Items satisfying the Definition of Done

Question 3

What is the main benefit of simultaneous card revelation in Planning Poker?

A. It eliminates the need for discussion

B. It reduces anchoring by an early estimate

C. It guarantees accurate estimates

D. It allows the product owner to choose the value

Correct Answer: B. It reduces anchoring by an early estimate

Question 4

A team completes items estimated at 3, 5 and 8 points. What is its velocity for the iteration?

A. 8 points

B. 13 points

C. 16 points

D. 24 points

Correct Answer: C. 16 points

Question 5

A backlog has 80 points and expected velocity is 20 points per iteration. What is the central iteration forecast?

A. 2

B. 3

C. 4

D. 5

Correct Answer: C. 4

Question 6

Which statement about capacity is correct?

A. It is always equal to velocity

B. It describes expected availability for future work

C. It measures business value delivered

D. It is a universal conversion from hours to points

Correct Answer: B. It describes expected availability for future work

Question 7

Why should teams avoid comparing velocity across different teams?

A. Velocity cannot be calculated

B. Teams may use different contexts and estimation practices

C. All teams must have identical backlogs

D. Velocity is a measure of individual performance

Correct Answer: B. Teams may use different contexts and estimation practices

Question 8

A team’s observed velocity ranges from 16 to 24 points. For 80 remaining points, which is a reasonable simple scenario range?

A. Exactly 3 iterations

B. Approximately 4 to 5 iterations

C. Exactly 6 iterations

D. Approximately 8 to 10 iterations

Correct Answer: B. Approximately 4 to 5 iterations

Question 9

What is false precision in release planning?

A. Using a range based on evidence

B. Recording assumptions beside a forecast

C. Giving an exact date unsupported by available evidence

D. Updating a forecast after new information

Correct Answer: C. Giving an exact date unsupported by available evidence

Question 10

Which practice best supports responsible Agile forecasting?

A. Treating velocity as a fixed target

B. Counting unfinished work as partial velocity

C. Hiding scope changes from stakeholders

D. Communicating assumptions, variation and confidence

Correct Answer: D. Communicating assumptions, variation and confidence