Overview¶

Estimation is one of the most misunderstood parts of agile practice — often reduced to "guessing story points." This guide covers the theory and practical techniques behind relative estimation, why it works better than absolute time estimates for creative/uncertain work, and how estimation differs between Scrum and Kanban contexts.

Who it's for: Scrum Masters, Product Owners, and Developers who want to run more accurate, less painful estimation sessions.

Core Topics Breakdown¶

1. Why Relative Estimation Beats Absolute Time Estimates¶

• Humans are poor at estimating absolute duration for novel/creative work but are comparatively good at relative comparison ("is this bigger or smaller than that other thing?").
• Cone of Uncertainty: estimates made early in a project (or feature) carry inherently wider error margins than estimates made closer to implementation — this is a mathematical reality of incomplete information, not a personal estimating failure.

2. Story Points¶

• A unitless, relative measure of effort/complexity/uncertainty for a backlog item, calibrated against a reference story the team agrees on.
• Fibonacci-like sequences (1, 2, 3, 5, 8, 13, 20, 40, 100) are commonly used because the increasing gaps force real distinctions rather than false precision at higher sizes.
• Story points are team-specific — one team's "5" is not comparable to another team's "5," which is why velocity should never be compared across teams.

3. Planning Poker¶

• Each estimator privately selects a card representing their estimate; all reveal simultaneously to avoid anchoring on the first spoken number.
• Large discrepancies (e.g., one person says 2, another says 13) are a signal to discuss — often surfacing hidden complexity or a shared misunderstanding of scope.
• Facilitation tip: cap discussion time per item to avoid analysis paralysis; if consensus can't be reached quickly, consider splitting the story or scheduling a spike.

4. T-Shirt Sizing and Other Lightweight Techniques¶

• T-shirt sizes (XS, S, M, L, XL) for very early, high-level estimation (e.g., roadmap-level epics) where precision isn't yet possible or useful.
• Affinity estimation / "bucket" sizing: quickly sorting a large batch of items into relative-size buckets without discussing each one individually — useful for backlog grooming at scale.
• Dot voting for relative complexity when speed matters more than precision.

5. Kanban-Specific Estimation Considerations¶

• Many mature Kanban teams move away from estimation entirely, instead tracking cycle time distributions for similarly-sized work and using historical data (Monte Carlo simulation) to forecast delivery dates probabilistically.
• "No estimates" approaches rely on consistently small, similarly-sized work items rather than pre-estimating each one — a valid alternative once a team has enough historical throughput data.

6. Forecasting From Estimates¶

• Velocity-based forecasting: average completed story points per Sprint × number of remaining Sprints = rough capacity forecast — always present as a range, not a single number.
• Monte Carlo forecasting: using historical cycle-time data to simulate thousands of possible delivery-date outcomes, producing a probability distribution (e.g., "85% likely to finish by March 15") rather than a single deterministic date.

Study Tips¶

• Practice running a mock Planning Poker session (even solo, estimating a personal task list) to internalize the simultaneous-reveal mechanic.
• Learn to calculate a simple velocity-based forecast range from a hypothetical set of the last 5 sprints' completed points.
• Understand conceptually how Monte Carlo forecasting differs from a simple average — it accounts for variability, not just central tendency.

Common Pitfalls¶

• Treating story points as a disguised time estimate (e.g., "1 point = 1 day") — this defeats the purpose of relative estimation and creates false precision.
• Comparing velocity across different teams as a performance metric — velocity is team-specific and not standardized.
• Estimating in absolute time for highly uncertain/novel work, then treating that estimate as a firm commitment.

Quick Reference Cheat Sheet¶

Further Practice¶

Take your last 5 completed Sprints' velocity numbers (or estimate hypothetically) and calculate a forecast range for how many Sprints it would take to complete a 100-point backlog.