Story Points Explained: Fibonacci & Examples

Story points are a relative way to estimate Agile work.

They do not measure hours. They measure the size of a backlog item compared with other backlog items your team understands.

A good story point estimate considers:

• effort
• technical complexity
• uncertainty
• dependencies
• testing and review effort
• risk against the sprint goal

For a quick first estimate, use the Story Point Calculator. For team consensus, use Planning Poker.

Quick Answer: What Are Story Points?

Story points are numbers Scrum and Agile teams use to estimate the relative size of work.

For a quick starting estimate, use the free Story Point Calculator. For a team decision, use Planning Poker so everyone votes before discussion.

Instead of asking:

How many hours will this take?

The team asks:

How big is this compared with work we have done before?

Example:

1 point: tiny, clear, low risk
3 points: moderate work, mostly understood
8 points: complex or uncertain, needs careful discussion
13 points: probably too large, split before sprint commitment

Story points are useful because software work is rarely predictable enough for precise hour estimates. They help teams talk about complexity and uncertainty before sprint planning.

Story Points at a Glance

Use this table as a starting point. Your team's calibration matters more than a universal definition.

Story Points vs Hours

Story points and hours answer different questions.

Hours feel precise, but they often hide uncertainty. A story might take 8 hours for one developer and 3 days for another because of context, codebase familiarity, review load, or test complexity.

Story points make that uncertainty visible.

Why Fibonacci Story Points?

Most Scrum teams use a Fibonacci-style sequence:

1, 2, 3, 5, 8, 13, 21

The larger the story, the less precise the estimate should be.

That is why the gaps grow.

If a team is debating whether a story is 8 or 13, the discussion is useful. If the team is debating whether it is 9 or 10, the conversation is probably fake precision.

What Goes Into a Story Point Estimate?

1. Effort

How much work is involved?

Questions to ask:

• How many parts of the system are touched?
• Is there UI, backend, data, and QA work?
• Does the story need documentation or release coordination?
• How much review and testing will be needed?

2. Complexity

How difficult is the work?

Questions to ask:

• Have we done similar work before?
• Is the implementation path clear?
• Are there tricky business rules?
• Are there security, permission, or data constraints?

3. Uncertainty

How much do we not know yet?

Questions to ask:

• Are acceptance criteria complete?
• Are dependencies confirmed?
• Do we understand the API, data, or design?
• Is a spike needed before estimation?

4. Risk

What could make the story harder than expected?

Questions to ask:

• Could this break an important existing flow?
• Is there release timing pressure?
• Does QA need special data or environments?
• Is another team involved?

Common Story Point Examples

These are examples, not rules. Calibrate them against your own team history.

For more examples, see Story Point Examples for Agile Teams.

How to Estimate Story Points

Use this simple flow in backlog refinement or sprint planning.

Step 1: Read the story

The Product Owner explains the user value and scope.

The team checks:

• user story
• acceptance criteria
• design or API notes
• dependencies
• Definition of Done

Step 2: Ask clarifying questions

The team should clarify anything that affects size or risk.

Good questions:

• What is in scope?
• What is explicitly out of scope?
• How will QA test this?
• Are there external dependencies?
• Does this need migration, rollout, or monitoring?

Step 3: Compare against a baseline story

Pick a completed story your team agrees was a 2 or 3.

Then ask:

Is this smaller, similar, or larger than that baseline?

This keeps estimation relative instead of turning it into hours.

Step 4: Vote independently

Use Fibonacci cards or a planning poker tool.

Everyone votes before seeing the others' estimate. This reduces anchoring.

Use Planning Poker when the team is remote or when disagreement matters.

Step 5: Discuss outliers

If one person votes 3 and another votes 8, the goal is not to average them.

Ask:

• What risk did the high estimate see?
• What assumption did the low estimate make?
• Is the story missing acceptance criteria?
• Should the story be split?

Step 6: Re-vote or split

After discussion, vote again.

If the estimate is still high or unclear, split the story or create a spike.

Planning Poker and Story Points

Planning poker is a team estimation technique.

The flow:

1. Product Owner presents the backlog item.
2. Team members choose a point card privately.
3. Cards are revealed at the same time.
4. High and low estimates explain their reasoning.
5. Team discusses assumptions.
6. Team re-votes or agrees on the estimate.

Planning poker works because it prevents one senior person from anchoring the estimate before everyone thinks independently.

Start a free session with Planning Poker.

How Story Points Become Velocity

Velocity is the number of story points a team completes in a sprint.

Example:

Average velocity:

(28 + 32 + 30) / 3 = 30 points per sprint

If the team usually completes about 30 points, planning 55 points for the next sprint is likely unrealistic unless capacity or scope changed.

Use Sprint Capacity Calculator when availability changes because velocity alone does not account for holidays, support load, or planned absence.

Story Points and Sprint Capacity

Story points help estimate size. Capacity helps decide how much work fits.

During sprint planning, compare:

• average velocity
• available team days
• planned meetings
• support or on-call load
• holidays and absence
• work already committed

Then choose a sprint scope that fits both the sprint goal and team capacity.

Use the Sprint Planning Checklist before final commitment.

When to Split a Story

Split a story when:

• it is 13 points or higher
• the team cannot explain the estimate
• acceptance criteria cover multiple workflows
• the story mixes UI, backend, migration, analytics, and release work
• there are too many unknowns
• it cannot be tested independently

Better split:

Story 1: User requests password reset email.
Story 2: User opens reset link and creates a new password.
Story 3: User sees clear errors for expired or invalid reset links.

Weak split:

Story 1: Build frontend.
Story 2: Build backend.
Story 3: Write tests.

Try to split by user-visible value, workflow, risk, or business rule.

Common Story Point Mistakes

Converting points to hours

If your team says "1 point equals 1 day," story points lose their value. Use points for relative size and uncertainty. Use hours only when you need a separate time discussion.

Estimating before the story is ready

If acceptance criteria, dependencies, or scope are unclear, use ? and refine the story before estimating.

Useful next step: AI Backlog Refinement Prompts.

Letting one person decide

Story points should be estimated by the team. Planning poker exists to reveal disagreement before commitment.

Comparing velocity across teams

A 30 point velocity on one team does not mean the same thing as 30 points on another team. Velocity is useful inside one team over time.

Treating carryover as completed points

Only count completed work that meets Definition of Done. Half-finished work should not inflate velocity.

Keeping huge stories in the sprint

Large stories hide risk. Split 13+ point stories before sprint commitment whenever possible.

Frequently Asked Questions

What are story points in Agile?

Story points are a relative estimate of effort, complexity, uncertainty, and risk. They help teams compare backlog items without pretending every story can be predicted precisely in hours.

Are story points the same as hours?

No. Hours estimate time. Story points estimate relative size and uncertainty. A 5 point story may take different time on different teams.

Why use Fibonacci for story points?

Fibonacci values create larger gaps as uncertainty increases. This prevents teams from wasting time debating fake precision.

Who estimates story points?

The developers who will do the work estimate together. The Product Owner clarifies value and scope, but the team owns the estimate.

Is a 13 point story too big?

Usually yes. It may still fit in one sprint for some teams, but it often means the work should be split.

Next Step

Use these resources together:

1. Story Point Calculator - get a quick estimate from effort, complexity, uncertainty, risk, and dependencies.
2. Planning Poker - estimate with the team and reveal votes simultaneously.
3. Story Point Examples for Agile Teams - compare against real examples.
4. Sprint Capacity Calculator - check how many points realistically fit in the sprint.