Story points are a relative team scale

What a point means

A story point has no fixed conversion to hours or days. It represents how large one item feels relative to other items for the same team. An item scored eight should feel meaningfully larger than an item scored three, but it does not have to take exactly a particular multiple of time.

This relative approach accepts that product work contains uncertainty. A small code change with a risky integration may deserve a larger estimate than its line count suggests. Conversely, a broad but familiar change may be easier than it first appears.

Build a reference scale

1. Select a few completed items the team understands well.
2. Choose a small item as an early reference, such as a two.
3. Add a medium and a larger reference that are clearly different.
4. For each new item, ask which reference it most resembles and why.
5. Refresh references when the product, architecture, or team changes materially.

Keep references concrete and accessible. They should prompt useful comparisons rather than become rigid formulas.

How to interpret velocity

Velocity is the amount of estimated work a team finishes in an iteration. It can help that team make near-term forecasts after enough stable iterations. It should not be used to rank individuals or compare teams. Changing point values to reach a target destroys the historical signal that made velocity useful.

Frequent mistakes

• Adding partial points for every task: estimate the item as a coherent outcome unless task-level planning genuinely helps.
• Forcing precision: use a bounded scale and split items that are too uncertain or too large.
• Never revisiting assumptions: if scope changes, explicitly decide whether the estimate still supports the forecast.
• Rewarding more points: points measure an internal estimate, not value delivered or individual performance.

Choosing a scale

Many teams use a modified Fibonacci sequence because the gaps widen as uncertainty grows. T-shirt sizes can work for early portfolio conversations, while a custom scale may fit specialized work. The best scale is the one the team understands and applies consistently. Continue with the Fibonacci estimation guide or review the broader agile estimation workflow.