Story points are a relative scale a team uses to compare pieces of work. A number is meaningful in relation to other stories the same team understands. The aim is to make differences in size, difficulty and uncertainty discussable, rather than to find a universal unit of developer productivity.
There is no standard answer to “How many hours is five points?” Two teams can use the same numbers while working from different references, skills and constraints.
What should a story point estimate include?
First agree what completion means for your team. Include the work needed to meet that definition, rather than estimating coding alone and discovering testing or review later. Then compare the whole story with familiar work.
Useful discussion prompts are: how much is there to change, how difficult are those changes, and what do we not yet know? Do not treat uncertainty as a mathematical surcharge. Explain it: an untested provider API is a different problem from simply having many small screens to update.
- Scope: implementation, review, testing, accessibility and deployment work that belongs to the story.
- Complexity: interactions, data rules, integrations and failure cases.
- Uncertainty: unclear requirements, unfamiliar tools or external dependencies.
Choose reference stories the team actually remembers
Pick a few completed items that people can describe without guessing. One small, familiar change and one medium change are a better starting point than a long list of abstract definitions. Keep a sentence about why each item received its estimate.
For a hypothetical product team, the reference set below might work. Another team could reasonably assign different numbers. The relationships and shared assumptions matter more than these exact values.
| Reference story | Illustrative points | Why it helps |
|---|---|---|
| Change a validation message and its test | 1 | Small scope with a familiar implementation |
| Add a filtered list using an existing API | 3 | Several states and tests, little new infrastructure |
| Add a new external provider with retry handling | 8 | Integration risk and unfamiliar failure cases |
When should you use a half-point card?
PointRoom includes ½ for a piece of work that is clearly smaller than your team's one-point reference. Use it if that distinction helps a real planning decision. There is no obligation to make tiny distinctions, and a half point does not mean half an hour.
Agree what zero means too. A team might use it for an item with no meaningful implementation work. If a story contains work you have not considered, calling it zero will not remove that work.
Why fixed hour conversions create confusion
A story point is not an individual time sheet. A familiar task may take different elapsed time depending on interruptions, review queues and who is available. Converting every point to a fixed number of hours can give a precise-looking answer while hiding those differences.
If you need a delivery forecast, discuss the team's available capacity and evidence from completed work separately. Make uncertainty visible. Do not compare two teams by their point totals or turn a person's estimates into a target to beat.
What to do when the scale drifts
If everything starts receiving an 8, compare a current item with a real reference story. Has the work changed, has the team learned something, or has the number become a habit? Update the reference explanation when it stops helping.
You do not need to rewrite historical estimates to make a chart look consistent. Use the next refinement conversation to reset the meaning of the scale, and record any change so later comparisons have context.
Sources and further reading
For the underlying methods and framework, start with these primary sources. Worked examples and suggested agendas above are illustrative.
A shared estimate starts with a shared table.
Create a free room, invite your team and try one clear story. No signup needed.
Create a free planning poker room