Estimation Basics in Scrum: Relative Sizing and Forecasting

Estimation Is for Forecasting, Not a Promise

In Scrum, estimation helps the team answer questions like: “How much can we likely finish in a Sprint?” and “When might a set of backlog items be done?” It is not a guarantee, a performance target, or a contract. Estimates are a decision-support tool that improves planning and transparency, especially when work has uncertainty.

A useful mindset is: estimate to reduce risk, not to create certainty. The goal is to make trade-offs visible (scope, time, risk) and to support forecasting based on evidence.

What Estimation Can and Cannot Do

• Can do: help compare items, support Sprint selection, enable release forecasting, surface uncertainty early, and guide conversations about scope and approach.
• Cannot do: predict the future precisely, eliminate unknowns, or replace learning from delivering increments.

Relative Estimation: Sizing by Comparison

Relative estimation means you size work items by comparing them to each other instead of trying to guess exact time. This works well because humans are better at comparison than absolute prediction.

What “Size” Usually Includes

When teams estimate relatively, they often implicitly include multiple factors:

• Complexity: how hard it is to implement or reason about.
• Uncertainty: how many unknowns exist (requirements, technical approach, dependencies).
• Effort: the amount of work likely needed (not hours, but relative amount).
• Risk: likelihood of rework, integration issues, or hidden constraints.

Teams should align on what “size” means for them. A simple shared definition is: “Size reflects effort + complexity + uncertainty.”

Continue in our app.

• Listen to the audio with the screen off.
• Earn a certificate upon completion.
• Over 5000 courses for you to explore!

Or continue reading below...

Download the app

Story Points

Story points are a relative unit used to compare items. A “5-point” item is not “5 days”; it is “about the size of other items we call 5.” Points become meaningful only within the same team over time.

Many teams use a non-linear scale (often Fibonacci-like) to reflect increasing uncertainty as items get bigger:

• 1, 2, 3, 5, 8, 13, 20

The gaps remind the team that larger items are harder to estimate precisely and may need splitting or discovery.

T-Shirt Sizes

T-shirt sizing is an even lighter relative approach: XS, S, M, L, XL. It is useful when you need quick sizing for many items or early-stage forecasting.

A practical way to use it is to map sizes to rough point ranges later if needed (without pretending it is exact). Example mapping:

Keep the mapping flexible. The value is in the shared comparison, not the conversion.

Lightweight Estimation Approaches

Planning Poker (Consensus-Based Estimation)

Planning poker is a structured way for Developers to converge on a shared estimate while surfacing assumptions and unknowns. It works best when the team already has a few reference items and a consistent scale.

Step-by-Step: Planning Poker

1. Pick a reference item the team agrees is, for example, a “3.” Keep it visible as an anchor.
2. Read the backlog item and clarify acceptance expectations. Ask: “What would make this done?”
3. Silent selection: each person chooses a point value privately.
4. Reveal together to avoid anchoring and groupthink.
5. Discuss outliers (highest and lowest). The goal is not to “win,” but to uncover missing information (edge cases, integration, data migration, testing, etc.).
6. Re-estimate after discussion. Repeat until the team reaches a reasonable consensus or a narrow range.
7. Capture key assumptions if they affect risk (e.g., “Assumes API supports filtering; otherwise add spike”).

Practical tip: Timebox discussion per item (e.g., 3–7 minutes). If it takes longer, the item is likely too unclear or too large and needs refinement, splitting, or discovery work.

Affinity Sizing (Fast Sorting by Relative Size)

Affinity sizing is a fast method to estimate many items by grouping them into relative buckets. It is useful when you have a large backlog and need a quick sizing pass for forecasting or prioritization.

Step-by-Step: Affinity Sizing

1. Prepare a scale on a wall/board (e.g., XS, S, M, L, XL or 1, 2, 3, 5, 8, 13).
2. Start with one item and place it as a baseline (e.g., “M” or “5”).
3. Place items quickly by comparison: “Is this bigger, smaller, or about the same as that baseline?” Avoid deep debate.
4. Allow movement: as understanding improves, move items between buckets.
5. Review outliers (very large or uncertain items). Mark them for splitting or discovery.
6. Optional calibration: pick 2–3 items per bucket and do a short planning poker round to validate consistency.

Practical tip: Use a “parking lot” for items that cannot be sized due to unknowns. Unknowns are information: they indicate where refinement or experimentation is needed.

Estimating with Uncertainty (and Making It Visible)

Uncertainty is normal. Good estimation does not hide it; it exposes it so the team can manage risk.

Techniques to Handle Uncertainty

• Use wider buckets for bigger work: if something feels like “8 or 13,” that uncertainty is a signal to split or learn more.
• Split by risk: separate “happy path” from “edge cases,” or “UI change” from “data migration.” Smaller items reduce uncertainty.
• Add discovery work intentionally: if the solution is unclear, create a timeboxed research item (often called a spike) with a concrete output (e.g., prototype, decision, or test results). Avoid open-ended spikes.
• Document assumptions: a short note like “Assumes single sign-on library supports X” helps later when forecasts change.

Example: Turning Uncertainty into Action

Backlog item: “Add export to CSV for reports.” During estimation, the team realizes there are unknowns about data volume and permissions.

• Split into: “Export basic fields,” “Export with permissions filtering,” “Handle large datasets (streaming),” “Audit logging.”
• Or add a short discovery item: “Validate export approach with 1M rows and permission checks; produce recommendation.”

This approach improves forecasting because it replaces vague uncertainty with smaller, more predictable work.

Using Past Throughput/Velocity Carefully

Once a team has delivered several Sprints, it can use historical delivery to forecast future delivery. If the team uses story points, this is often called velocity (points completed per Sprint). If the team does not use points, it can use throughput (items completed per Sprint) or other evidence-based measures.

Guidelines for Responsible Use

• Use ranges, not single numbers: if the last 6 Sprints were 18, 20, 17, 22, 19, 16 points, forecast with a range like 16–22 rather than “19.”
• Prefer recent data: the last 3–6 Sprints usually reflect current reality better than older data.
• Account for known changes: holidays, onboarding, major tech changes, or new dependencies can shift delivery. Adjust expectations explicitly rather than pretending the past will repeat exactly.
• Do not compare across teams: points are team-specific. A “5” in one team is not equivalent to a “5” in another.
• Use completed work only: count only items that meet the team’s done criteria. Partial completion distorts forecasting.

Simple Forecasting Example (Points)

If a team’s recent completed points per Sprint are: 18, 20, 17, 22, 19, a reasonable forecast might be:

• Likely range: 17–20
• Stretch range: up to 22 if things go smoothly

For a backlog slice totaling 60 points, the forecast becomes roughly 3–4 Sprints, not “exactly 3.2 Sprints.” The range communicates uncertainty honestly.

How Estimation Influences Sprint Selection Without Becoming a Contract

Estimates help the team make a realistic selection of work for a Sprint and understand trade-offs. They should not be used to lock scope or punish variance. The Sprint is a short learning cycle; new information can emerge after work starts.

Practical Approach to Using Estimates During Selection

• Start with a capacity signal: use recent delivery (points or throughput) as a guide, adjusted for known availability changes.
• Favor a coherent set of items: choose work that fits together toward a meaningful outcome, rather than maximizing the number of points.
• Leave room for uncertainty: if the Sprint includes risky items, plan below the historical average to reduce spillover.
• Watch for hidden work: integration, testing, reviews, and operational tasks can consume capacity even if not obvious in backlog items.

Example: Using a Buffer for Risk

If the team typically completes around 20 points, but this Sprint includes a new integration with unknown behavior, the team might select around 16–18 points plus a small discovery item. This is not “under-committing”; it is risk-aware planning.

Common Pitfalls (and What to Do Instead)

Pitfall: Comparing Individuals by Points

Why it hurts: it encourages gaming, discourages collaboration, and breaks the meaning of points as a team measure.

Do instead: treat estimates and delivery as team-level signals. Use them to improve refinement, reduce uncertainty, and remove impediments.

Pitfall: Converting Points to Hours Rigidly

Why it hurts: it turns relative sizing into a false precision system, reintroducing the same problems as time-based guessing, and often leads to micro-management.

Do instead: if stakeholders need time forecasts, use empirical delivery (e.g., “We usually finish 17–20 points per Sprint”) and translate at the release level with ranges and assumptions, not per-item hour conversions.

Pitfall: Over-Precision and False Accuracy

Why it hurts: estimating “7.5 points” or “42 hours” implies certainty that does not exist, especially for knowledge work.

Do instead: use coarse scales and focus on splitting large items. If an item feels like it needs decimals, it is likely not well understood.

Pitfall: Treating Estimates as Commitments

Why it hurts: it discourages learning and adaptation, and can lead to cutting quality to “hit the number.”

Do instead: use estimates to support selection and forecasting, then inspect actual progress and adapt. When reality differs from estimates, treat it as feedback: “What did we learn?”

Pitfall: Estimating Without Shared Understanding

Why it hurts: estimates become noise if people are estimating different interpretations of the same item.

Do instead: before estimating, clarify the expected behavior, key constraints, and major edge cases. If clarity is missing, size the uncertainty explicitly (larger bucket) or create discovery work.

Pitfall: Using Estimation to Hide Dependencies

Why it hurts: forecasts fail when external waiting time is ignored.

Do instead: call out dependencies during estimation. If an item depends on another team or vendor, reflect that risk by splitting, sequencing, or adding explicit coordination work.