Estimation and Velocity

Software estimation is famously unreliable, yet teams need some forecast. Agile estimation accepts uncertainty and uses relative sizing, group conversation, and historical data to produce useful forecasts without faking precision.

Why Not Hours?

• Hours imply individual capacity; teams deliver as teams.
• Estimating in hours invites comparison to "how long would I take" — pure cognitive bias.
• Hours conflate effort, complexity, and risk — three different things.
• Once an "8-hour" estimate exists, anyone late by 1 hour feels like a failure.

Story Points

A unit of relative size. Three story points is not three hours — it is three times the size of a one-point story. Size combines effort, complexity, and uncertainty.

The Fibonacci scale

1, 2, 3, 5, 8, 13, 21 (sometimes including 0.5, 100, "?"). Gaps grow because larger items have more uncertainty — distinguishing 14 from 17 points is meaningless. The Fibonacci jump forces a "we just don't know" answer for very large items, signalling they need to be split.

T-shirt sizes

XS, S, M, L, XL. Less precise; great for early-stage roadmap discussions where points feel false-precise.

Anchoring with Reference Stories

Pick a small completed story everyone remembers and call it 1. Or pick a typical mid-size story and call it 3. Estimate everything new relative to that anchor. Without an anchor, story points become the team's private dialect.

Planning Poker

The classic estimation technique:

1. Product Owner reads the story; team asks clarifying questions.
2. Each member privately picks a card with a Fibonacci value.
3. Reveal simultaneously.
4. Discuss the lowest and highest. The high one usually saw a risk; the low one usually saw a simpler solution.
5. Repeat until convergence (rarely more than two rounds).

The value is not the number — it is the conversation. Stories where the team reveals 1 / 1 / 8 / 13 are exactly the ones that need a five-minute discussion before being committed.

Velocity

Velocity is the average number of story points the team completes per Sprint. Used to forecast — not to evaluate performance.

Calculating

Sum points of stories that met the Definition of Done in the Sprint. Average over the last 3–5 Sprints. Tail-bound by historical worst case for risk-aware planning.

Forecasting

Backlog items remaining for goal: 80 points
Velocity (rolling 3 Sprints):     10 points/Sprint
Forecast:                         ~8 Sprints, +/- 2

Range using best/worst Sprint:    6 to 12 Sprints

Always communicate forecasts as ranges, not single numbers.

Velocity Anti-Patterns

• Velocity as quota. "We need 25 points this Sprint." Engineers immediately inflate estimates to hit it. Velocity goes up; throughput does not.
• Velocity comparison across teams. Each team's points mean different things. Comparing teams' velocity is meaningless and harmful.
• Carrying over points. Stories partially done at end of Sprint do not count. Either it met DoD or it did not.
• Hiding spikes and bugs. If the team only points "feature work," velocity hides the real cost of operating the product.

Burndown and Burnup Charts

Visualise Sprint or release progress.

• Burndown: remaining work over time, sloping toward zero.
• Burnup: completed work plus total scope, both rising lines. Better at showing scope changes.

Useful as conversation starters, not as truth. A pretty burndown can hide a Sprint where the team did the wrong work.

The No-Estimates School

An influential strand of Agile argues estimates are waste. Their alternative:

• Slice stories so they are roughly the same size.
• Count stories, not points, to forecast.
• Use cycle time (start-to-done) as the leading indicator.
• Trust historical throughput like Kanban does.

For mature teams with disciplined slicing, no-estimates often outperforms point estimation because it eliminates a meeting and the social games around it. For new teams, the conversation in planning poker is still valuable, even if the number is not.

Probabilistic Forecasting (Monte Carlo)

Take historical throughput per Sprint or per day, sample randomly thousands of times, and produce an 85th-percentile finish date. Better than averages because it captures variability.

Tools: Actionable Agile, Jira plugins, simple Python scripts. The output looks like:

50% chance: 6 weeks
85% chance: 9 weeks
95% chance: 12 weeks

Stakeholders can pick the confidence level they need.

What Should Move the Estimate?

• Effort. How much work to do.
• Complexity. How tangled the logic, how many systems involved.
• Uncertainty. How much we do not know.

What should not move it: who is doing the work, how much pressure exists, what management hopes the answer is.

A Healthy Stance

• Estimate to plan, not to commit.
• Use ranges, not single numbers.
• Re-forecast as you learn — every Sprint at least.
• If estimates feel like a weapon, the team will protect itself by inflating them. Trust matters.

Cert Mapping

The next module steps outside Scrum to look at flow-based work with Kanban.