Estimation and Forecasting

Why estimate at all?

Every organization asks "when will it be ready?" and "what can we have by March?". Estimates help answer those questions, but in complex work, where much is unknown until you start, no estimate is exact. The Scrum Guide (2020) is clear about the limits: forecasting practices "do not replace the importance of empiricism", and only what has already happened may be used for forward-looking decisions.

Estimation is still useful, for three reasons:

• Forecasting. A rough idea of size lets the Product Owner plan releases and talk honestly with stakeholders.
• Conversation. When one Developer thinks an item is tiny and another thinks it is huge, they understand it differently. Finding that out before starting is often the most valuable result of estimating.
• Trade-offs. Knowing that an item is large helps the Product Owner decide whether it is worth it, or whether a smaller slice would do (see splitting items).

An estimate is not a promise. The Scrum Guide speaks of the Developers' forecast during Sprint Planning; the commitment for a Sprint is the Sprint Goal, not a number of items or points.

The examples follow the Portal team at Kestrel Energy: Product Owner Isabel Santos, Scrum Master Lars de Boer and the Developers Ravi Kumar, Sofia Lindqvist, Kwame Asante, Priya Shah and Bram Peeters, in two-week Sprints.

Relative estimation

Relative estimation means sizing work by comparing it with other work instead of predicting hours or days: "this is about twice as big as the login fix we did last month". People are poor at predicting absolute durations, but fairly consistent at saying which of two things is bigger. Relative sizes also stay valid when the team gets faster or slower, because the comparison does not change.

Size here means everything that makes an item big: the amount of work, its complexity and its uncertainty. An item that is small but touches a system nobody understands is not small.

Story points

A story point is a unitless number for the relative size of a Product Backlog item. A team picks a reference item ("updating the meter reading form was a 3") and sizes everything else against it. Points mean something only within one team.

Story points come from Extreme Programming, where teams first estimated in "ideal days" multiplied by a load factor, and renamed them to points to avoid confusion with calendar days. Ron Jeffries, one of the XP originators, later wrote: "I may have invented story points, and if I did, I'm sorry now" (Story Points Revisited, 2019). His concern was how organizations started using points: to compare teams and to put pressure on them.

Fibonacci-like scales

Most teams use a limited set of values that grow further apart as they get bigger, such as 1, 2, 3, 5, 8, 13, 20, 40 and 100 (a "modified Fibonacci" sequence). The gaps express uncertainty: nobody can tell a 14 from a 15, but everybody can tell a 13 from a 20. Some teams use T-shirt sizes (XS, S, M, L, XL) instead, which avoids the temptation to do arithmetic with them.

Anything at the top of the scale is a signal rather than a size: "this is too big and too unclear to estimate; split or explore it first".

Planning poker

Planning poker is a consensus-based estimation game. It is generally traced to James Grenning (2002) and was popularized by Mike Cohn's books.

1. The Product Owner explains an item, and the Developers ask questions.
2. Each Developer privately chooses a card with a size and everyone turns their cards over at the same time.
3. If the values differ, the people with the highest and lowest cards explain their reasoning.
4. The team votes again until the values are close enough.

The simultaneous reveal is the point: it stops the most senior person's opinion from anchoring everyone else. At Kestrel, Sofia shows a 3 for the usage chart and Bram a 13. Bram knows that the usage data lives in a database that cannot handle the extra query load; after a short discussion the team agrees on 8 and adds a caching question to the item.

Only the people who will do the work estimate. The Product Owner and Scrum Master do not vote unless they are also doing the work as Developers.

Velocity

Velocity is the amount of work a team completes in a Sprint, usually measured as the sum of the story points of items that met the Definition of Done. Items that are almost done count as zero.

Used well, velocity is a range that helps a team judge how much to take into the next Sprint and helps the Product Owner forecast further ahead:

# Story points Done in the last six Sprints
done_per_sprint = [21, 18, 25, 19, 23, 20]

low, high = min(done_per_sprint), max(done_per_sprint)
average = sum(done_per_sprint) / len(done_per_sprint)
remaining = 120

print(f"Range: {low} to {high} per Sprint (average {average:.1f})")
print(f"{remaining} points left: {remaining / high:.1f} to {remaining / low:.1f} Sprints")

Range: 18 to 25 per Sprint (average 21.0)
120 points left: 4.8 to 6.7 Sprints

"Five to seven Sprints" is a more honest answer than "5.7 Sprints", and it still assumes the 120 points stay 120 points, which they rarely do.

Three rules keep velocity useful:

• It is not a target. When velocity becomes a goal, estimates quietly grow and the number goes up while nothing changes. This is Goodhart's law, in Marilyn Strathern's popular phrasing: when a measure becomes a target, it ceases to be a good measure.
• Never compare teams. A point in one team is not a point in another. Ron Jeffries calls comparing teams by velocity harmful.
• Expect it to vary. Holidays, sickness, incidents and new team members all move it. A sudden change is a reason to talk, not to blame.

Burn-down and burn-up charts

A burn-down chart plots the work remaining against time; the line should head toward zero by the end of the Sprint or release. A burn-up chart plots two lines: the work completed, rising over time, and the total scope. Where the lines meet, the work is done.

Because a burn-down shows only what is left, it cannot tell you why the line went up on day 5: did the team lose ground, or did someone add work? The burn-up answers that question, which is why many teams prefer it for release forecasts.

Cumulative flow diagrams, the third practice the guide names, are explained on the Kanban page.

Probabilistic forecasting

A single date ("done on 14 March") hides the uncertainty that every forecast contains. A probabilistic forecast gives a range with a likelihood instead: "a 50% chance within 9 Sprints, 85% within 10". The stakeholder can then choose how much certainty they need.

A Monte Carlo forecast produces such a range by simulation. It simulates the future thousands of times by repeatedly drawing a randomly chosen past Sprint's throughput: each simulated future Sprint finishes as many items as that past Sprint did, and the simulation keeps going until the remaining work is finished. Counting how often each outcome occurs gives the probabilities. No story points are needed; the team only counts how many items it finished per Sprint.

Isabel wants to know when the 60 items for the new app release will be done. The team finished between 3 and 11 items per Sprint over the last ten Sprints:

import random
from collections import Counter

random.seed(42)  # same "random" result every run

# Items finished in each of the last 10 Sprints (oldest first)
throughput = [6, 9, 4, 11, 7, 3, 10, 8, 5, 9]
remaining = 60
trials = 10_000

results = []
for _ in range(trials):
    done = 0
    sprints = 0
    while done < remaining:
        done += random.choice(throughput)  # replay a random past Sprint
        sprints += 1
    results.append(sprints)

counts = Counter(results)
for sprints in sorted(counts):
    print(f"{sprints:>2} Sprints: {counts[sprints] / trials:6.1%}")

results.sort()
for p in (50, 85, 95):
    print(f"{p}th percentile: {results[p * trials // 100 - 1]} Sprints")

 6 Sprints:   0.2%
 7 Sprints:   8.6%
 8 Sprints:  32.3%
 9 Sprints:  35.3%
10 Sprints:  18.1%
11 Sprints:   4.5%
12 Sprints:   0.9%
13 Sprints:   0.1%
50th percentile: 9 Sprints
85th percentile: 10 Sprints
95th percentile: 11 Sprints

The 85th percentile means: in 85% of the simulated futures the work was finished within 10 Sprints. Isabel tells stakeholders "most likely 9 Sprints; with 85% confidence 10", and the team runs the simulation again every Sprint with the newest data. If scope grows, the forecast moves, and everybody can see why.

The method assumes the future looks roughly like the recent past: similar team, similar kind of work, items of similar size. When the team changes or the work changes character, the history needs time to catch up.

#NoEstimates

#NoEstimates is a movement that questions whether detailed estimates are worth their cost. It started as a Twitter hashtag around 2012 and is usually associated with Woody Zuill, Vasco Duarte and Neil Killick. The core suggestion is practical rather than radical: split work into items of roughly similar, small size, then simply count them and forecast from throughput, as in the Monte Carlo example above.

It does not mean "never think about size". Teams still discuss whether an item is small enough; they just stop arguing about whether it is a 5 or an 8. Critics point out that some decisions, such as a budget for a large investment, still need a size estimate up front.

Estimation anti-patterns

Other warning signs: the Product Owner or a manager overriding the Developers' estimates; hours of debate over the difference between two neighboring values; re-estimating finished items to make velocity look better; and "partial points" for unfinished work.