Story Points and Estimation

The Scrum Guide states that the Developers are responsible for estimating Product Backlog items, and that the Product Owner may influence the Developers by helping them understand and select trade-offs, but does not dictate the estimate. Nowhere does it prescribe a unit, a scale, or a technique. Story points, ideal days, t-shirt sizes, and no-estimates approaches are all compatible with Scrum as written.

This is a deliberate gap. Scrum defines the empirical structure, events, artifacts and accountabilities, and leaves specific engineering and estimation practices to be chosen by the team based on what actually helps them plan.

Story points are a relative estimation technique: instead of estimating in hours, which people are notoriously bad at doing accurately, teams compare the size of one item to another using an abstract unit, often following a Fibonacci-like sequence such as 1, 2, 3, 5, 8, 13. The claim behind this technique is that people are better at relative comparison, 'this is about twice as big as that,' than at absolute time prediction.

Over several Sprints, a team's velocity, the average number of story points completed per Sprint, can be used to forecast roughly how much future work might fit into upcoming Sprints, which is genuinely useful for longer-range planning conversations with stakeholders.

The single most damaging misuse of story points is comparing velocity across different teams, or using it as an individual productivity metric. Story points are relative and team-specific by design; one team's five-point item bears no relationship to another team's five-point item, so comparing them is comparing two different, arbitrary units and drawing false conclusions.

A second common failure is spending excessive time debating precise point values for items that will not be worked on for months, when the Scrum Guide's own guidance is that items further down the Product Backlog can remain coarse and imprecise until they get closer to being worked on.

A third failure is treating an estimate as a promise. An estimate is a forecast based on current understanding; when the Developers learn more mid-Sprint, the plan is expected to change, and holding the original point estimate as a fixed commitment defeats the purpose of empirical planning.

• Story points are relative, team-specific, and not comparable across teams
• Estimation technique is a team choice, not a Scrum Guide requirement
• Velocity is a planning aid, not a productivity or performance metric
• Coarser estimates are fine for items far down the Product Backlog

Some teams use no-estimates approaches, breaking work into similarly small pieces and tracking throughput instead of size. Others use t-shirt sizing for early, coarse categorization before Product Backlog refinement adds detail. None of these are more 'correct' according to Scrum, since the Scrum Guide takes no position on the technique; the right choice depends on what actually helps a given team plan honestly.

Estimates, in whatever unit a team chooses, feed directly into Sprint Planning's forecast and into Product Backlog refinement, where items get sized as they move up the backlog. They should never leak into performance evaluation or cross-team comparison, since doing so corrupts the honesty the whole estimation exercise depends on.