Estimation and Forecasting

Welcome to Agile Planning and Metrics. You now face a critical challenge: how do you plan when change is constant, estimate when uncertainty is high, and measure progress when outcomes matter more than outputs?

In this lesson, you’ll learn practical ways to:

• Estimate without pretending you can predict the future in hours.
• Forecast using real delivery data and ranges (not single dates).
• Communicate uncertainty in a way stakeholders can act on.

Relative estimation works because humans are poor at absolute estimation but strong at comparison. Instead of “How long?”, ask: “Is this bigger or smaller than that work we did last time?”. Planning shifts from guesswork to a practice teams can trust and improve.

Work can be partitioned into (user) stories, a small, testable slice of customer value, e.g.:

• As a customer
• I want to reset my password
• So that I can regain access

A story is “done” when it meets acceptance criteria (e.g., email sent, token expiry, rules enforced, tests passing). Estimation techniques include story points, T-shirt sizing , and #NoEstimates.

Story points (1, 2, 3, 5, 8, 13, 21) represent a blend of effort, complexity, and uncertainty. Teams set a few anchors (reference stories) and estimate by comparison. Consistency over time matters more than “precision”.

It is important to keep in mind that points are team-specific, meaning that it is up to the team to decide what the points represent and when breaking down to smaller tasks is needed.

Example anchors:

• 1 point: change button label text
• 3 points: add a profile field + validation + tests
• 8 points: integrate a new external API (auth + errors)

T-shirt sizing (XS–XL) is another way to estimage, usually used for quarter planning. And example of this type of estimation can look like this:

• S: ~1–2 days
• M: ~3–5 days
• L: likely needs splitting

Many teams size a quarter in t-shirts, then convert near-term items into story points.

By contrast, #NoEstimates approaches this practice differently. If you split work until items are roughly uniform, you can skip estimating and forecast by throughput (items finished per sprint).

Example:

• If a team typically finishes 7–9 items per sprint, you can project roughly 30–35 items next month (depending on sprint count).

Here is a quick comparison:

Whatever you choose, use reference stories and recalibrate in restrospective meetings (“That 5 felt like an 8—should we adjust?”). Accuracy improves through shared understanding, not finer guesses.

Agile planning treats uncertainty as normal. When asked “When will it be done?”, answer with ranges:

• “Based on recent delivery, we’re 85% confident we’ll finish in 4–6 iterations.”

Velocity is a forecasting input, not a commitment and not a productivity score. It tells us that, given the output of recent sprints, what amount of work can be done in the future.

Monte Carlo uses real delivery variability. Feed it either Throughput (items finished per sprint), or Cycle time (days per item). It is used to produce probability dates (e.g. 50% by April 15, 85% by May 1 or 95% by May 15).

Data you need:

• 10–15 iterations of data
• Either throughput per sprint or cycle time per item
• A consistent definition of Done

When someone asks for one date, offer a choice:

• “Do you want the 50% date (more aggressive) or the 90% date (more conservative)?”
  Then make trade-offs explicit in scope, cost, and risk.

Communicating uncertainty is harder than managing it. Translate probability into decisions stakeholders can use.

Tailor by audience:

• Executives (outcome windows + options): “85% for core by Q3; 95% if we simplify scope.”
• Sales / customer-facing (confidence tiers): “Guaranteed by June; highly likely by July; possible by August.”
• Engineering (data + distribution): Show history, assumptions, and how the range was produced.

A conversation between management and leadership might looks something like this:

• Victoria: I need a firm date for the customer portal launch. The board wants to announce it.
• Jessica: I can give confidence levels. We’re 50% by June 15, and 85% by July 1.
• Victoria: I still need something I can say out loud.
• Jessica: Announce core availability June 15. Position advanced analytics as rolling out through July. That’s honest and gives you certainty for the announcement.
• Victoria: Good. Send the data so I can defend it.

Jessica doesn’t abandon probabilistic thinking—she turns it into options tied to outcomes and expectations.

Replace single-date roadmaps with visuals that show confidence and risk. This helps make uncertainty intuitive.

As you deliver and learn, the stakeholders can literally see uncertainty shrinking.

Estimate relatively rather than in hours. Use story points, t‑shirt sizes, or #NoEstimates (split small and forecast by throughput). Anchor sizing with reference stories and recalibrate in retros—accuracy comes from shared understanding, and point scales are team-specific.

Treat velocity as capacity, not productivity. Plan with ranges, and use Monte Carlo with real throughput or cycle time to forecast probability dates instead of brittle deadlines.

Communicate uncertainty in business terms and tailor it by audience. Visualize with confidence fade. Maintain a steady cadence: what shipped, what changed, and updated ranges—plus a forecast log to calibrate over time.