Agile Estimation, Forecasting and Release Planning

Introduction

Agile product development treats plans as hypotheses that are revised as evidence accumulates. This principle is especially important in estimation and release planning. A product team must make decisions about scope, timing, staffing, investment and customer communication, yet the work itself contains uncertainty: requirements change, technical discoveries emerge, dependencies fail, and team capability varies. An estimate is therefore not a promise. It is an evidence-based approximation used to support a decision.

Traditional project environments often seek a single precise estimate for cost and completion date before substantial learning has occurred. Agile approaches instead emphasize relative estimation, empirical measurement and probabilistic forecasting. The objective is not to eliminate uncertainty but to make it visible, manage it responsibly and update forecasts as actual delivery data becomes available.

This chapter explains story points, planning poker, velocity, throughput, cycle time, capacity analysis and probabilistic forecasting. It also shows how these concepts support release planning without turning estimates into fixed commitments.

Learning Objectives

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

1. Explain the purpose and limitations of relative estimation.
2. Apply story points and planning poker appropriately.
3. Distinguish velocity, throughput, cycle time and capacity.
4. Construct simple deterministic and probabilistic forecasts.
5. Plan releases using confidence ranges rather than false precision.
6. Evaluate risks, dependencies and ethical issues in communicating forecasts.
7. Use empirical evidence to revise plans and product decisions.

1. Estimation as Decision Support

An estimate is a prediction about an uncertain future outcome. In product development, the outcome may be effort, duration, delivered scope or cost. These are related but not identical dimensions.

A useful distinction is:

• Effort: the amount of work required.
• Duration: elapsed calendar time.
• Capacity: the amount of work a team can reasonably undertake during a period.
• Scope: the product functionality or outcomes intended for delivery.
• Forecast: a prediction derived from assumptions and evidence.
• Commitment: an explicit organizational promise, normally involving an agreed level of accountability.

Agile estimation is primarily intended to improve decisions. For example, a product manager may use a forecast to compare two release options, decide whether to reduce scope, or determine whether a date is feasible. The forecast should not be presented as certainty when the evidence does not support certainty.

Three sources of uncertainty are particularly important:

1. Aleatory uncertainty, arising from natural variation in delivery, such as differing task complexity.
2. Epistemic uncertainty, arising from limited knowledge, such as an unfamiliar technology or unclear customer need.
3. Interaction uncertainty, arising from dependencies among teams, suppliers, systems or stakeholders.

Early in a product initiative, epistemic uncertainty is usually high. Discovery, prototyping and incremental delivery reduce it. Consequently, forecasts should normally become more reliable over time, although they can become less reliable again when major scope or technology changes occur.

2. Relative Estimation and Story Points

2.1 The logic of relative estimation

Relative estimation compares work items with one another rather than attempting to assign an absolute number of hours. A team may agree that Item B is approximately twice as large as Item A, while avoiding the claim that Item A will take exactly eight hours.

A relative estimate commonly reflects several dimensions:

• amount of work,
• technical complexity,
• uncertainty and learning required,
• integration difficulty,
• testing effort, and
• likely coordination overhead.

Story points are a team-specific scale for expressing relative size. Many teams use a nonlinear sequence such as 1, 2, 3, 5, 8, 13 and 21. The increasing gaps communicate that larger items are harder to distinguish precisely. The sequence is not a universal unit and should not be converted into hours across teams.

A story point does not mean “one day,” “one developer” or “one unit of customer value.” It is an ordinal or approximate interval-like indicator of relative work size within a particular team and product context.

2.2 Establishing reference stories

A team should select a few completed or well-understood items as reference stories. For example:

• a small, familiar change may be assigned 2 points;
• a moderately complex change may be assigned 5 points;
• a large, uncertain integration may be assigned 13 points.

New items are compared with these anchors. Reference stories should remain visible and should be revisited if the team’s understanding changes. The purpose is calibration, not mathematical perfection.

2.3 Decomposing large items

A product backlog item that is too large to estimate confidently should be split. Useful splitting techniques include separating:

• workflow steps,
• user roles,
• business rules,
• data variations,
• happy path and exception path,
• read and write operations, or
• technical slices that produce demonstrable value.

Splitting is not merely an estimation technique. It reduces risk, creates earlier feedback and improves flow. A 21-point item should not automatically be treated as three 7-point items; decomposition may expose different levels of complexity and uncertainty.

3. Planning Poker and Collaborative Estimation

Planning poker combines individual judgment with group discussion. A typical procedure is:

1. The product owner explains the item and acceptance criteria.
2. Team members ask clarifying questions.
3. Each estimator privately selects a point value.
4. All participants reveal their values simultaneously.
5. The highest and lowest estimates explain their reasoning.
6. The group discusses assumptions and votes again.
7. The team records the estimate, unresolved risks and any follow-up action.

The method reduces anchoring, a cognitive bias in which the first number stated influences later judgments. It also reveals different mental models. A high estimate may reflect security testing, while a low estimate may assume an existing integration. The discussion is therefore often more valuable than the final number.

Planning poker has limitations. It can become ritualistic, be dominated by senior voices, or create false consensus. A facilitator should invite minority views, distinguish uncertainty from effort and stop discussion when additional precision is not useful. If an item cannot be estimated because essential information is missing, the correct action may be a time-boxed spike or discovery task rather than a forced estimate.

4. Velocity: Use and Misuse

Velocity is the amount of estimated work a team completes in an iteration. If a team completes 18, 22 and 20 story points in three comparable sprints, its average velocity is:

The unit is story points per sprint. The calculation assumes that the team, point scale, sprint duration and definition of done are sufficiently stable.

A rolling average over the most recent n comparable iterations is commonly expressed as:

Here, Vᵢ is the completed velocity in iteration i, n is the number of iterations, and V̄ is average velocity.

Velocity can support a simple forecast. If 80 points remain and expected velocity is 20 points per sprint, the nominal forecast is:

This is not a guarantee. It assumes stable team membership, comparable work, no major interruptions and no material scope change. It also hides variation. If recent velocities were 15, 20, 25 and 20, the mean is 20, but an outcome based on the mean alone does not show the range of plausible results.

Velocity should not be used to compare teams. Point scales are local, and optimization against velocity can produce harmful behavior: inflating estimates, selecting easy work, reducing quality or pressuring teams to increase the number. Velocity is a planning instrument, not a productivity score.

5. Flow Metrics: Throughput and Cycle Time

5.1 Throughput

Throughput is the number of work items completed in a specified period. If a team completes 12, 9, 10 and 13 items in four weeks, total throughput is 44 items and average weekly throughput is:

Throughput is particularly useful when work items are similarly sized or when the organization uses a flow-based system such as Kanban. If item sizes vary substantially, throughput alone may mislead. A team can complete many tiny items while making little progress on strategically important work.

5.2 Cycle time

Cycle time is the elapsed time from a defined start point, such as “in progress,” to a defined completion point, such as “done.” It must be measured consistently. If five items have cycle times of 3, 5, 4, 8 and 5 days, the mean cycle time is:

The median is 5 days, which may better represent a typical item because the 8-day item has less influence on the median. Percentiles are often more useful for commitments. A ��90th-percentile cycle time of 9 days means that approximately 90% of observed comparable items were completed within 9 days; it does not mean that every future item will finish within 9 days.

5.3 Little’s Law

For a stable system, Little’s Law relates work in progress, throughput and average cycle time:

Equivalently:

Where WIP is the average number of items in progress, throughput is items per unit of time, and cycle time uses the same time unit. The relationship assumes a stable long-run system: items enter and leave at approximately the same rate, the system is not accumulating unlimited work, and the averages are measured over a sufficiently representative period.

For example, if average WIP is 12 items and throughput is 3 items per week:

Little’s Law is not a promise for an individual item. It is a relationship among long-run averages. It highlights why starting more work does not necessarily accelerate delivery. If throughput remains constant, increasing WIP increases average cycle time.

6. Capacity Analysis

Capacity analysis asks how much time or effort is realistically available. It is useful for sprint planning and release planning, but it should not be confused with story-point velocity.

A simple capacity calculation is:

The availability factor represents the proportion of nominal time available for the product work being planned. It should account for leave, support duties, meetings, training and other obligations.

Suppose four people have 10 working days, 6 nominal productive hours per day and an availability factor of 0.75:

The assumptions are important. “Productive hours” should not be interpreted as a demand that people work continuously at maximum intensity. The calculation is a planning approximation, not a surveillance mechanism.

Capacity is useful when the team composition or calendar changes. Velocity is useful when historical delivery data is available. A new team may begin with capacity-based planning and then transition toward empirical forecasting as completed-work data accumulates. Converting hours into story points by a universal formula is inappropriate because points are relative and team-specific.

7. Probabilistic Forecasting

7.1 Why probability matters

A deterministic forecast states one outcome, such as “the release will be complete in six sprints.” A probabilistic forecast states a range and confidence level, such as “there is an estimated 85% chance of completing the selected scope within eight sprints.” The latter communicates uncertainty more honestly.

Forecasts can be based on historical velocity, throughput or cycle-time data. The method should match the workflow and data quality. A forecast based on a small, unstable or non-comparable sample should be presented with particular caution.

7.2 A simple velocity-range forecast

Assume a team has recent velocities of 15, 18, 20, 22 and 25 points per sprint. The mean is:

For 80 remaining points, the mean-based estimate is 4 sprints. A conservative range using observed minimum and maximum velocities gives:

Since iterations are discrete, this suggests approximately 4 sprints in a central scenario, with a broad plausible range of 4 to 6 completed sprints when rounding up and allowing for variation. This method is simple but not a formal probability distribution. It should not be described as an 85% confidence forecast unless a suitable statistical method has been applied.

7.3 Monte Carlo simulation

A more informative approach samples historical observations repeatedly. For a throughput forecast, each simulated period randomly selects a throughput value from the historical data, accumulates completed items and records how many periods are required to reach the target. Repeating this process many times produces a distribution of completion dates.

For example, if historical weekly throughput is [8, 9, 10, 12, 13] and the target is 40 items, a simulation might produce the following interpretation:

• 50th percentile: completion in about 4 weeks;
• 85th percentile: completion in about 5 weeks;
• 95th percentile: completion in about 6 weeks.

These values are illustrative rather than calculated from a complete simulation. The precise result depends on the sampling method, the number of trials and whether the historical data is representative.

A basic simulation algorithm is:

1. Collect comparable historical throughput observations.
2. Define the target scope and time unit.
3. For each trial, randomly sample historical throughput values.
4. Add sampled throughput until cumulative delivery reaches the target.
5. Record the number of periods used.
6. Repeat many trials.
7. Report selected percentiles and inspect the assumptions.

The result is conditional: it means “given data and assumptions of this kind.” It is not a guarantee and does not predict unprecedented events such as a major platform failure or a radical scope change.

7.4 Confidence and decision language

Confidence levels should be connected to decisions. A date for a marketing campaign may require a high confidence level, while an internal exploration may tolerate a lower one. The higher the desired confidence, the more scope flexibility, time buffer or contingency may be required.

Good language distinguishes:

• forecast: “Based on the last 20 comparable weeks, the 85th-percentile forecast is…”
• target: “The organization would like to achieve…”
• deadline: “A date imposed by an external event is…”
• commitment: “The team and stakeholders have agreed to…”

A target should not be relabeled as a forecast merely to make it appear evidence-based.

8. Release Planning Without Fixed Commitments

Release planning aligns product outcomes, scope, timing, capacity and risk. It is not simply the act of assigning backlog items to a date.

8.1 The release-planning triangle

A release plan usually balances three variables:

• Scope: what will be delivered;
• Time: when it is needed;
• Resources or capacity: what delivery capability is available.

Quality should not be treated as a negotiable corner of this triangle. A release that meets date and scope by omitting testing, accessibility or security is not a successful release.

If time and capacity are relatively constrained, scope should remain flexible. The product manager can prioritize a minimum valuable outcome, define optional scope and identify items that can be deferred without undermining the product objective.

8.2 Release-planning process

A disciplined process is as follows:

1. Define the product outcome. State the customer or business result, not merely a list of features.
2. Establish a minimum valuable release. Identify the smallest coherent outcome that can generate learning or value.
3. Refine and order the backlog. Clarify acceptance criteria, dependencies and relative size.
4. Estimate or measure the work. Use story points, throughput or other suitable evidence.
5. Assess capacity. Consider team availability, holidays, support load and external constraints.
6. Create a forecast range. Use historical velocity, throughput or cycle-time data where available.
7. Identify risks and assumptions. Include technical uncertainty, suppliers, regulation and operational readiness.
8. Choose a planning policy. For example, fixed date with variable scope, or fixed minimum scope with a forecast date.
9. Review at regular intervals. Reforecast after each iteration or when material evidence changes.
10. Communicate confidence and options. Present alternatives rather than one falsely exact date.

8.3 Fixed-date and fixed-scope situations

Some contexts impose a date: a legal requirement, contract, seasonal event or hardware launch. In such cases, the team should not pretend that uncertainty has disappeared. Instead, it can:

• define a minimum compliant or valuable scope;
• rank optional features;
• use progressive elaboration;
• reserve contingency for integration and defects;
• perform early risk-reduction experiments; and
• communicate what will be omitted if the forecast deteriorates.

Where scope is fixed, a release date should be represented as a range with confidence. Where date and scope are both externally fixed, management must address capacity, technical risk and contingency explicitly; no estimation technique can guarantee feasibility.

9. A Detailed Illustrative Case: Community Banking App

Background

The fictional company Northstar Bank is developing a mobile feature that allows customers to freeze a payment card, report a suspicious transaction and request a replacement. The release is strategically important because fraud-related support calls are increasing. The product manager wants to launch before the next high-volume holiday period, 12 weeks away.

Problem

The initial backlog contains 96 story points. The team has completed the following velocities in the last five comparable two-week sprints: 18, 21, 16, 24 and 19 points. A simple average is:

The team has six weeks of effective delivery time before the planned operational freeze, equivalent to three sprints. A nominal forecast based on the mean would be:

Therefore, completing all 96 points is not credible under current capacity.

Analysis

The backlog contains several items that are not essential to the customer outcome: a customizable card image, historical freeze explanations and a complex analytics dashboard. The essential journey requires authentication, card freeze, fraud report, replacement request and customer notifications.

The team also identifies a dependency on the card processor. The integration has never been tested in production-like conditions, making the point estimates less reliable. The product manager therefore creates a small technical spike in the first sprint and treats the integration as a major forecast risk.

Approach and solution

The team reorganizes the backlog into:

• Minimum valuable release: 49 points;
• Important but deferrable scope: 27 points;
• Optional scope: 20 points.

Using the historical velocities, the team recognizes that three sprints may deliver approximately 48 to 72 points, but this is a broad range and not a formal confidence interval. The product manager chooses the 49-point minimum release as the target scope and makes the 27-point group conditional on actual progress.

The release plan includes:

1. a processor-integration spike in Sprint 1;
2. a tested end-to-end customer journey before optional reporting features;
3. explicit security and accessibility acceptance criteria;
4. a weekly review of remaining scope and forecast;
5. a go/no-go decision based on operational readiness, not feature count alone.

Outcome

At the end of Sprint 1, the processor integration reveals an additional compliance step. Two optional items are removed, and the minimum release is revised to 52 points. The team completes 20, 18 and 19 points over the next three sprints. The essential customer journey is released after the operational team completes monitoring and support training. The analytics dashboard is deferred.

Learning points

First, the original 96-point request was not a feasible release scope within the available period. Second, relative estimates supported comparison but did not remove integration uncertainty. Third, early discovery changed the plan before the final release window. Fourth, the release succeeded because scope was managed as a variable while quality and customer safety remained protected. Finally, the forecast was used as a decision tool rather than a promise that punished the team when new information appeared.

10. Governance, Ethics and Organizational Behaviour

Estimation and forecasting influence funding, performance assessment and customer expectations. They therefore have ethical and governance implications.

Avoiding metric-driven harm

Using velocity as an individual or team performance target encourages gaming. Managers may see rising point totals and conclude that productivity has improved, even when estimates have inflated. Similarly, throughput targets can encourage teams to split work artificially or avoid valuable complex items.

Metrics should be used for system learning. Appropriate questions include:

• Is work becoming smaller and easier to validate?
• Are blocked items increasing?
• Is cycle-time variation reducing?
• Are defects and rework affecting throughput?
• Are we delivering the intended customer outcome?

Honest communication

Forecasts should state their data source, time period, assumptions and confidence. A product manager should disclose when a forecast excludes leave, support work, technical debt or dependency risk. Reporting a single date without this context creates an avoidable governance failure.

Inclusion and psychological safety

Estimation discussions can be affected by hierarchy, culture and communication style. Silent disagreement may conceal important technical or customer risks. Anonymous voting, rotating facilitation and explicit invitations to dissent can improve the quality of the estimate. Psychological safety is not only a cultural benefit; it is a condition for reliable risk information.

Responsible use of AI

AI tools can summarize backlog items, identify similar historical work or assist with simulation. They should not be treated as authoritative estimators. AI-generated forecasts may reproduce incomplete historical data, overlook dependencies or express unjustified precision. Human review is required, especially for safety-critical, regulated or privacy-sensitive products. Teams should document data sources and avoid exposing confidential customer or employee information to unapproved systems.

11. Contemporary Practices and Best Practices

Modern product organizations increasingly combine Scrum events with flow metrics. A Scrum team may use story points for collaborative refinement while monitoring throughput, cycle-time distribution, blocked time and escaped defects. This combination is useful because no single metric captures delivery performance.

Evidence-based release planning should follow these practices:

1. Estimate only to the precision required for the decision.
2. Use relative points within a team, never as a universal productivity currency.
3. Prefer completed historical data over optimism or managerial pressure.
4. Separate forecasts, targets, deadlines and commitments.
5. Use ranges and confidence levels when uncertainty is material.
6. Reforecast after meaningful changes in scope, team, technology or dependencies.
7. Split large work and reduce uncertainty early.
8. Protect quality, security, accessibility and compliance from being silently traded away.
9. Present multiple options, such as reduced scope, additional capacity or later release.
10. Evaluate whether delivery produced the intended product outcome, not merely whether points were completed.

Challenges and Limitations

Agile estimation remains imperfect. Story points are subjective and may be inconsistent when team membership changes. Velocity is sensitive to estimation conventions and cannot be compared meaningfully across teams. Throughput forecasts fail when item size changes substantially or when historical data is not representative. Cycle-time data can be distorted by hidden queues, pauses or inconsistent definitions of “started” and “done.”

Probabilistic models may create an illusion of scientific authority. A simulation based on biased or inadequate data produces a precise-looking but unreliable result. Forecasts also cannot fully anticipate discontinuities such as major outages, acquisitions or regulatory changes. Finally, excessive estimation can consume time that would be better spent discovering the product through delivery.

The appropriate response is not to abandon estimation. It is to treat estimates as conditional evidence, make assumptions explicit, select metrics appropriate to the system and revise decisions as learning occurs.

Chapter Summary

Agile estimation supports decisions under uncertainty rather than promising certainty. Relative estimation and story points help teams compare work, expose assumptions and avoid false precision. Planning poker improves shared understanding when it is facilitated inclusively and followed by clarification or discovery where necessary.

Velocity measures completed estimated work per iteration, while throughput measures completed items per unit of time. Cycle time measures elapsed time for an item, and capacity describes the realistically available effort. Little’s Law connects average work in progress, throughput and cycle time under stable-system assumptions. These measures answer different questions and should not be substituted for one another.

Probabilistic forecasting communicates ranges and confidence more honestly than a single date. Monte Carlo simulation can use historical observations to estimate completion percentiles, but the result remains conditional on data quality and assumptions. Release planning should begin with a valuable product outcome, prioritize a minimum valuable release, assess capacity and dependencies, and use scope flexibility where possible. Quality and compliance should not be treated as expendable variables.

Effective product managers distinguish forecasts from targets and commitments, communicate uncertainty transparently, avoid harmful metric incentives and update plans when evidence changes. The central principle is empirical: plan sufficiently to make a good decision, deliver in small increments, inspect results and adapt.

Key Terms

Relative estimation: Comparing the size of work items with one another rather than assigning absolute time values.

Story point: A team-specific, relative indicator of work size, complexity and uncertainty.

Planning poker: A collaborative estimation technique using simultaneous individual votes and structured discussion.

Reference story: A completed or well-understood item used as an anchor for estimating other work.

Velocity: The amount of estimated work completed by a team in an iteration.

Throughput: The number of work items completed per unit of time.

Cycle time: Elapsed time from a defined work-start point to a defined completion point.

Work in progress (WIP): Items that have started but are not yet complete.

Capacity: The realistically available effort during a specified period.

Forecast: An evidence-based prediction about a future outcome.

Confidence level: The stated degree of assurance associated with a forecast range.

Monte Carlo simulation: Repeated random sampling used to model possible future outcomes.

Percentile: A value below which a specified percentage of observations falls.

Release plan: A current plan linking product outcomes, scope, timing, capacity and risk.

Minimum valuable release: The smallest coherent release capable of delivering meaningful value or learning.

Dependency: A relationship in which delivery of one item relies on another team, system, supplier or event.

Epistemic uncertainty: Uncertainty caused by incomplete knowledge.

Aleatory uncertainty: Uncertainty caused by natural variation in outcomes.

Little’s Law: The stable-system relationship WIP = Throughput × Average cycle time.

Technical spike: A time-boxed investigation intended to reduce technical or domain uncertainty.

Review Questions

Short Answer Questions

1. Why is an estimate not necessarily a commitment?
2. What dimensions may story points represent?
3. Define velocity and explain one assumption required when using it for forecasting.
4. How does throughput differ from cycle time?
5. State Little’s Law and identify its three variables.

Long Answer Questions

1. Explain the purpose, procedure and limitations of planning poker.
2. Compare story points, velocity, throughput and capacity as planning concepts.
3. Explain why probabilistic forecasting is generally more informative than a single deterministic release date.
4. Describe a release-planning process for a product with a fixed external deadline.
5. Discuss the ethical risks of using velocity or throughput as performance targets.

Analytical / Application Questions

1. A team completed 14, 18, 17 and 23 story points in its last four comparable sprints. Calculate the average velocity and use it to produce a nominal forecast for 72 remaining points. Explain why the result should not be treated as a guarantee.
2. A flow system has average WIP of 15 items and throughput of 5 items per week. Calculate average cycle time using Little’s Law. State the assumptions required for interpreting the result.
3. A release has 80 points remaining, but the team can deliver only three sprints before a market event. Historical velocity ranges from 16 to 24 points per sprint. Recommend a product-management response, including scope, risk and communication actions.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a story point?

A. A universal unit equal to one developer-day

B. A team-specific relative measure of work size and uncertainty

C. A guaranteed amount of customer value

D. A contractual commitment to deliver a feature

Correct Answer: B. A team-specific relative measure of work size and uncertainty

Question 2

A team completes 18, 22 and 20 story points in three comparable sprints. What is its average velocity?

A. 18 points per sprint

B. 19 points per sprint

C. 20 points per sprint

D. 22 points per sprint

Correct Answer: C. 20 points per sprint

Question 3

What is the principal purpose of simultaneous voting in planning poker?

A. To guarantee identical estimates

B. To prevent all discussion of uncertainty

C. To reduce anchoring by revealing independent judgments

D. To convert points directly into hours

Correct Answer: C. To reduce anchoring by revealing independent judgments

Question 4

A team has average WIP of 12 items and throughput of 3 items per week. Under stable-system assumptions, what is average cycle time?

A. 3 weeks

B. 4 weeks

C. 9 weeks

D. 36 weeks

Correct Answer: B. 4 weeks

Question 5

Which metric counts completed work items per unit of time?

A. Throughput

B. Capacity

C. Story points

D. Cycle time

Correct Answer: A. Throughput

Question 6

Which is an appropriate use of velocity?

A. Comparing productivity across unrelated teams

B. Setting an individual developer performance quota

C. Supporting a forecast for the same team under comparable conditions

D. Proving that scope cannot change

Correct Answer: C. Supporting a forecast for the same team under comparable conditions

Question 7

What does a 90th-percentile cycle-time forecast mean?

A. Every future item will finish within that time

B. Approximately 90% of comparable observed items finished within that time

C. The team will work at 90% capacity

D. The estimate is 90% larger than the mean

Correct Answer: B. Approximately 90% of comparable observed items finished within that time

Question 8

A capacity calculation should normally account for which factor?

A. Only nominal working hours, ignoring leave and support work

B. Availability for the planned product work

C. The story-point scale of every other team

D. The number of backlog items regardless of size

Correct Answer: B. Availability for the planned product work

Question 9

What is a sound response when a fixed release date makes the full backlog infeasible?

A. Silently reduce testing

B. Increase story points until the plan appears feasible

C. Prioritize a minimum valuable release and identify deferrable scope

D. Treat the original estimate as a guarantee

Correct Answer: C. Prioritize a minimum valuable release and identify deferrable scope

Question 10

What is a key limitation of a Monte Carlo forecast?

A. It cannot use historical observations

B. It always produces a single certain date

C. Its reliability depends on representative data and assumptions

D. It eliminates the need for product judgment

Correct Answer: C. Its reliability depends on representative data and assumptions