Story Points

Plain English explanation

Story Points help a team compare one item of work with another. Instead of asking, “How many hours will this take?”, the team asks, “How big is this compared with work we already understand?” They are about relative size, not exact time.

Why it matters

Story Points help teams discuss uncertainty, complexity, and effort before selecting work for a Sprint. Used well, they support better forecasting, clearer Product Backlog refinement, and more realistic Sprint Planning.

How it works

The Developers compare Product Backlog items and assign a point value based on relative size. Many teams use a Fibonacci-style scale such as 1, 2, 3, 5, 8, and 13 because larger work usually contains more uncertainty.

Example

If a small text change is estimated as 1 Story Point, a simple form update might be 3 points, while a feature with several unknowns might be 8 points. The numbers are meaningful only inside that team’s own context.

Common myths

Story Points are not time, deadlines, or a measure of individual productivity. They should not be used to compare people or teams.

Key points

• Story Points estimate relative size, not exact hours
• They usually consider effort, complexity, risk, and uncertainty
• They are commonly used during Product Backlog refinement or Sprint Planning
• The Developers doing the work are responsible for sizing
• They can support velocity, but velocity should be used carefully
• Story Points are a common practice, not a required Scrum rule

What are Story Points in Scrum?

Story Points are a common estimation technique used by many Scrum Teams. They help Developers estimate the relative size of Product Backlog items before or during Sprint Planning. A larger point value usually means the item is bigger, more complex, riskier, or less understood.

Story Points vs hours

Story Points should not be converted directly into hours. Hours try to predict time, while Story Points compare the relative size of work. Two people may take different amounts of time to complete the same item, but the item can still have the same relative size for the team.

Why teams use Fibonacci numbers for Story Points

Many teams use a scale such as 1, 2, 3, 5, 8, and 13. The gaps between numbers get larger, which helps teams avoid false precision. When work is bigger, the uncertainty is usually bigger too, so the estimate should not look too exact.

Story Points and Product Backlog refinement

Story Points are often discussed during Product Backlog refinement, when Product Backlog items are clarified, broken down, and sized. The Scrum Guide does not prescribe Story Points, but it does say that Product Backlog refinement may add details such as description, order, and size.

Story Points and velocity

Velocity is the amount of estimated work a team completes over a Sprint or over several Sprints. Teams may use velocity to support forecasting, but it should be treated as a team planning signal, not as a performance target.

Common mistakes with Story Points

Common mistakes include treating Story Points as hours, forcing every team to use the same scale, comparing teams by velocity, using points to pressure people, and estimating without enough discussion. Story Points work best when they create shared understanding, not when they become a reporting weapon.

Are Story Points required in Scrum?

No. Story Points are not required by Scrum. They are a common Agile and Scrum-related practice that some teams use for sizing and forecasting. A Scrum Team may use Story Points, t-shirt sizes, simple item counts, or another approach that helps them understand and plan their work.