Story Points

What it is

Story points measure relative effort using a non-linear scale, most commonly the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21). The non-linearity reflects a simple truth: as work gets larger, uncertainty grows disproportionately. The gap between a 5 and an 8 is meaningful; the gap between an 8 and a 9 is indistinguishable.

Teams begin by establishing baseline stories — reference points everyone agrees on — and estimate new stories relative to these anchors. A story assigned 3 points should feel roughly three times the effort of a 1-point baseline story.

Points include all effort required to get a story to "done": coding, testing, code review, documentation, deployment, and any coordination. They intentionally abstract away the question of "how many hours?" and instead answer "how big is this compared to that?"

When to use it

Story points are used during backlog refinement and sprint planning for all user stories that require team effort. They are not typically applied to tasks, bugs (unless they are large), or operational work unless those items are significant enough to plan around.

The primary benefits of using story points include:

• Speed: Relative estimation is faster and less contentious than breaking every story into hourly tasks.
• Accuracy: Teams generally converge on consistent relative sizing over time, even as team composition changes.
• Completeness: Points naturally account for complexity, uncertainty, and risk — not just typing speed.
• Velocity tracking: The sum of points completed per sprint (velocity) gives a stable forecasting signal.

Key concepts

Relative Estimation

Instead of guessing absolute duration, the team compares stories to each other. A 2-point story is roughly twice the effort of a 1-point story. A 5-point story is roughly five times the effort. This leverages the human ability to judge "bigger than" or "smaller than" far more reliably than "how long."

The Fibonacci Scale

The standard scale is 1, 2, 3, 5, 8, 13, 21, and sometimes 34. Some teams use a modified Fibonacci or powers of two. The key principle is the increasing gap between numbers as values grow — this mirrors the widening uncertainty cone for larger work items.

Baseline Stories

Every team needs anchors. Pick 2–3 recent stories the team agrees on — one small (1 or 2 points), one medium (3 or 5 points), one large (8 points). Write them on the wall or in your wiki. When a new story comes up, ask: "Is this bigger or smaller than our 3-point baseline?"

Factors Affecting Points

Story points are not just about how long something takes. They deliberately fold in three factors:

• Complexity — How intricate is the logic? How many systems interact?
• Uncertainty — How well do we understand the requirements and the solution?
• Risk — What could go wrong? Are there dependencies, external vendors, or new technology?

A simple task in an unfamiliar technology may score higher than a complex task in a well-known codebase because uncertainty and risk inflate the effort.

Team-Specific Nature

Story points are not comparable across teams. A 5 for Team A is not the same as a 5 for Team B. Each team has its own baseline, its own domain knowledge, and its own definition of "done." Points are a local currency for planning, not a universal metric for management dashboards.

Common pitfalls

• Converting points to hours: Once management or the team starts mapping 1 point = 4 hours, you lose all the benefits of relative estimation. Resist the urge. Velocity exists precisely to bridge the gap between points and time.
• Re-estimating after the fact: Changing a story's points because it took longer than expected corrupts your velocity data. The point value reflects the estimate at the time; the variance is feedback, not an error to correct.
• Comparing points across teams: This is a common management anti-pattern. It leads to gaming, normalisation, and loss of team ownership over estimation.
• Letting the Product Owner pressure lower estimates: The PO's role is to clarify and prioritise, not to negotiate points downward. Estimates are owned by the developers doing the work.
• Excessive debate between adjacent numbers: Arguing over whether a story is a 3 or a 5 for ten minutes is wasted time. If the team can't agree, take the higher number and move on.

NZ context

In New Zealand's typically small, cross-functional agile teams, story points provide a common language for discussing scope without falling into the "how many hours?" trap that misunderstands knowledge work. Many NZ organisations operate with flat hierarchies and high trust; in these cultures, points work well because the team owns the estimate without management interference.

Conversely, in more traditional NZ enterprises or government agencies where time-tracking and billing are tightly coupled, teams sometimes face pressure to convert points to hours for reporting. In these environments, it's worth educating stakeholders that velocity (points per sprint) already gives them the forecasting signal they need — without breaking the estimation model.

NZ teams often include a mix of permanent staff and contractors. Story points help level the playing field: a senior contractor and a junior permanent employee can both contribute to estimation without the stigma of "you should know how long this takes."

Career level guidance

Junior

• Listen during estimation sessions and ask questions about why a story is sized a certain way.
• Participate in planning poker even if you feel uncertain — your fresh perspective is valuable.
• Learn the team's baseline stories so you can compare new work against known references.
• Avoid equating points directly to hours in conversation with stakeholders.

Senior

• Lead by explaining the "why" behind your estimates; model the inclusion of complexity, uncertainty, and risk.
• Help the team identify when a story is too large or ambiguous and should be split or spiked.
• Protect the team from external pressure to re-estimate or normalise points across teams.
• Track velocity trends and flag when the team's capacity signal is drifting.

Test Lead

• Ensure testing effort is explicitly considered during estimation, not treated as an afterthought.
• Advocate for including test automation, regression coverage, and exploratory testing in the point value.
• Watch for stories that consistently underestimate testing complexity — this is a common blind spot.
• Use velocity and burn-down data to forecast when quality debt is accumulating.