Agile Estimation Techniques: A Practical How-To Guide
Estimation in agile is different from estimation in traditional project management in two important ways. First, it is relative rather than absolute: instead of saying "this task will take 3 days," a Scrum team says "this story is about the same size as that one we delivered last sprint." Relative sizing is faster, more consistent, and less prone to the false precision of hour-by-hour breakdowns. Second, agile estimates are for planning purposes, not for commitment. A story-point estimate is not a promise that the story will be done by a specific date; it is an input into the team's capacity forecast, which improves as the team accumulates velocity data over multiple sprints. Both of these distinctions matter when introducing estimation to a team that is used to the traditional model.
Planning Poker: how and why it works
Planning Poker is the most widely used agile estimation technique. The Product Owner reads a backlog item; each team member privately selects a card representing their estimate (typically using a Fibonacci-like scale: 1, 2, 3, 5, 8, 13, 20, or similar); then everyone reveals simultaneously. When estimates converge, the team moves on. When they diverge, the highest and lowest estimators explain their reasoning, and the team discusses until it reaches a shared understanding — then re-estimates.
The simultaneous reveal is not incidental — it is the point. In sequential estimation, early voices anchor the group. Someone senior says "this is a 5" and everyone else adjusts toward that number. Simultaneous reveal forces independent judgment before the social dynamic kicks in, which consistently produces better estimates than anchored discussion. The discussion between high and low estimators also surfaces hidden assumptions: the developer who estimated 13 may be accounting for a dependency that the developer who estimated 3 was not aware of.
T-shirt sizing, affinity mapping, and forecasting
T-shirt sizing for epics. When estimating epics — large bodies of work that span multiple sprints — story points are too granular to be meaningful. T-shirt sizes (XS, S, M, L, XL, XXL) give the team a relative order-of-magnitude feel without implying precision that does not exist at the epic level. T-shirt sizes are typically converted to story-point ranges once the epic is being broken down into stories.
Affinity mapping for large backlogs. When a team faces a backlog of 50-plus items and needs rough sizing quickly, affinity mapping groups items by perceived size without requiring individual discussion of each. Items are placed on a wall in relative order; the team silently moves items to adjust; discussion focuses only on the edge cases. A full backlog can be roughly sized in under an hour.
Velocity-based forecasting. Once a team has three or more sprints of velocity data, the total story points in the backlog divided by average velocity gives a rough number of sprints to completion. Use a range — based on low and high velocity — rather than the average alone, and widen the range as the backlog extends further out. The honest version of a release forecast is not "we ship in Sprint 14" but "at current velocity, we expect to ship between Sprint 12 and Sprint 16."
When estimates are consistently wrong
If a team consistently over- or under-estimates, the instinct is often to "fix the estimates" — to adjust every score up or down. That approach treats the symptom, not the cause. The more useful question is whether the reference story is calibrated correctly. Every team's estimation relies on an implicit anchor: the story that a 1 is calibrated against, or the story that exemplifies a 5. If the team has grown or the type of work has shifted, the reference stories may no longer reflect current reality. Re-calibrate by picking two or three stories the team completed recently, agreeing on their sizes, and using those as the new anchor for the next session.
A separate issue is when external pressure — from management, stakeholders, or the Product Owner — leads the team to underestimate so that more stories fit in the sprint. This inflates the commitment without changing the actual capacity, and consistently produces sprints that fail to meet their goal. The fix is not better estimation; it is separating the discussion of what to build from the discussion of how much work fits. Velocity provides the constraint; the Product Owner's priority ordering decides what goes in. Neither side should be negotiating the estimates.
If your Scrum teams are finding that sprint goals are missed more often than met, XNM's program and project delivery advisory can help diagnose whether the issue lies in estimation, capacity planning, backlog quality, or sprint cadence.