What Are Story Points?

Story points are a unit of measure for estimating the relative effort required to complete a user story or task. They capture a combination of complexity, uncertainty, and the amount of work involved. Story points are relative, not absolute: they compare the effort of one item to another rather than mapping to specific hours or days.

Why story points matter

Time-based estimates are consistently inaccurate for software development. A task estimated at “two days” might take four if an unexpected edge case surfaces. Story points sidestep this by focusing on relative effort. The team agrees that Story A is about twice as complex as Story B, without committing to a specific number of hours. Over multiple sprints, the team's velocity (total points completed per sprint) stabilizes, making future planning more predictable.

Story points also enable meaningful comparisons across sprints. If the team completed 30 points last sprint and 28 the sprint before, their capacity is stable. If it drops to 15, something changed. This signal would be invisible with hour-based estimates because actual hours worked vary for many reasons.

How story points work

During backlog grooming or sprint planning, the team estimates each item using a point scale. The most popular approach is “planning poker”: each team member privately selects an estimate, then all estimates are revealed simultaneously. If estimates diverge, the team discusses why and converges on a number. This process surfaces different understandings of the work and improves estimate accuracy.

A calibration reference helps new teams get started. Pick a well-understood story that has been completed and call it a “2.” Then estimate other items relative to that baseline: “This feels about twice as complex as our reference, so it is a 5.” Over time, the team develops shared intuition about what each point value means.

Common mistakes

• Equating story points to hours, which defeats the purpose of relative estimation.
• Using story points to measure individual developer productivity, which creates perverse incentives.
• Changing the scale or calibration frequently, making velocity trends meaningless.
• Spending too long debating estimates when a quick conversation would suffice.

Related terms

• Velocity

  The total story points completed per sprint, used for planning

• User Story

  The work item that story points are applied to

• Backlog Grooming

  The session where story point estimation typically happens