Story Points

Estimating software work in hours is notoriously unreliable. People underestimate, tasks turn out to be harder than expected, and an estimate made by one developer may mean something quite different for another. Story points take a different approach. Instead of asking how many hours a piece of work will take, the team asks how big it is compared with other work it already understands. A small, well-understood change might be a 1, while something twice as large or uncertain might be a 2 or a 3. The numbers have no meaning on their own, only in relation to each other. Because they are relative, a team can estimate quickly without breaking work into detailed tasks.

Story points emerged from Extreme Programming in the late 1990s and became common in Scrum teams through the 2000s, often estimated using planning poker and a modified Fibonacci sequence. They are also among the most debated agile practices. Ron Jeffries, one of the early figures associated with them, has said he regrets how they are often used, especially when turned into productivity targets. For developers, product owners, Scrum Masters and managers, understanding what story points can and cannot do helps avoid their most common misuses.

Definition of Story Points

Story points are an abstract, relative measure of the size of a user story or other backlog item, reflecting the combined effort, complexity and uncertainty involved, used by a team to estimate how much work it can take on and to forecast delivery based on its historical rate of completion.

They are often estimated using planning poker, are summed into sprint velocity and inform Sprint Planning.

How Teams Estimate

The team picks a small, well-understood item as a reference point, often worth 1 or 2 points.

Each new item is compared with the reference and other estimated items, and given a number that reflects its relative size.

Many teams use a modified Fibonacci scale, such as 1, 2, 3, 5, 8, 13 and 20, so the gaps grow with size and reflect growing uncertainty.

In planning poker, each person reveals an estimate at the same time. Large differences prompt a discussion, which often uncovers hidden assumptions or risks.

What Story Points Include

Effort covers the amount of work needed, such as coding, testing and review.

Complexity covers how difficult the work is, such as unfamiliar code or tricky logic.

Uncertainty covers how much is unknown. Items with many unknowns get higher estimates or are investigated first with a short spike. Story points deliberately ignore who will do the work. The estimate reflects the team's view of the item, not the speed of a particular person.

Importance of Story Points in Delivery and Engineering Operations

Story points support planning. Teams can use their recent average to decide how much work to take into a Sprint.

They enable forecasting. Knowing the total points in a backlog and the team's average rate helps estimate when a set of work might be finished.

The estimating conversation itself is valuable. Discussing why estimates differ helps the team share understanding of the work before starting it. Relative estimation is also faster than detailed hour-based estimates, since people judge relative size better than absolute duration.

Story Points and Financial Management

Combining backlog size in points with a team's cost per Sprint gives a rough estimate of the cost of delivering a set of features. These estimates are best used for comparing options and setting expectations, not as fixed budgets.

Story points are team-specific, so they cannot be compared across teams or converted directly into money or hours. A 5 for one team may be a 3 or an 8 for another, depending on its reference stories and experience.

Using points as productivity targets encourages inflation, which makes forecasts and cost estimates less reliable.

Some organizations find that counting completed items, combined with cycle time, forecasts just as well with less estimating effort.

Common Challenges

Managers often compare velocity between teams or set velocity targets, which leads teams to inflate estimates.

Teams sometimes convert points back into hours, losing the benefit of relative estimation.

Estimating sessions can take a long time, especially for large backlogs, and the precision gained may not justify the effort. Points can drift over time as the team's understanding changes, which makes comparisons across long periods unreliable.