Estimation Pitfalls in Scrum: A Beginner-Friendly Explainer

Estimation is the process of approximating the effort required to complete a piece of work. In Scrum, estimation is used to help the team understand the size of their backlog relative to their capacity, to facilitate Sprint Planning (how much can we commit to this Sprint?), and to forecast when work will be done. Estimation is not a commitment -- an estimate is an approximation under uncertainty, and treating it as a precise promise is one of the most common misuses of the practice.

Here are the most important estimation pitfalls for Scrum teams and how to avoid them.

Pitfall 1: Estimating in Hours Instead of Relative Size

Estimating in hours assumes that everyone on the team will complete the same task in the same time, which is rarely true. It also encourages false precision -- a story that is estimated at 4 hours feels more precise than one estimated at 'medium,' but the apparent precision is illusory. Story points or T-shirt sizing (S/M/L/XL) estimate relative effort and complexity compared to a reference story, which is more honest about uncertainty and avoids anchoring to a specific time commitment.

Pitfall 2: Estimating Without the Whole Team

Estimation is most valuable as a conversation, not as a number. When the team estimates together, differences in estimates reveal differences in understanding -- a developer who estimates a story at 5 points and a tester who estimates it at 13 have a different mental model of what the story requires. The conversation that reveals and resolves that difference is more valuable than the final estimate. Estimation done by one person and assigned to the team defeats this purpose.

Pitfall 3: Using Velocity as a Commitment

Velocity -- the number of story points a team completes per Sprint -- is a planning tool, not a performance metric. It should be used to forecast future Sprint capacity based on historical throughput. It should not be used to compare teams (different teams use story points differently), to set performance targets (optimising for velocity encourages gaming), or to hold the team accountable for completing exactly the estimated number of points per Sprint (velocity varies naturally between Sprints).

Pitfall 4: Estimating Without a Shared Definition of Done

A story point estimate is meaningless without a shared understanding of what 'done' means. A story estimated at 3 points assuming it requires development and unit testing only is very different from a story estimated at 3 points assuming it requires development, unit testing, integration testing, documentation, and sign-off by the product owner. The Definition of Done should be agreed upon and stable before estimates are useful for planning.

XNM supports public-sector organisations in building effective agile delivery teams, including estimation and Sprint planning practices. Reach out to XNM's program & project delivery advisory team to discuss agile estimation and Sprint planning for your team.