Story points examples: a reference scale from 1 to 13
Six backlog examples to help your team compare work, question assumptions, and choose its own reference stories.
A story-point estimate expresses the relative size of work for one team, considering effort, complexity, and uncertainty. That makes a completed, familiar item a useful reference for discussing the next one. Atlassian’s estimation guide explains this relative approach.
For example, a team might give a familiar settings change 2 points and a new notification workflow 5. The useful question is: what additional work explains the difference?
The examples below belong to a fictional team building a shared document workspace. They are starting points for a conversation, not standard prices for features. Your team can reasonably choose different values.
Six examples on one team's scale
Assume this team already has a component library, workspace permissions, a notification service, and automated checks around its existing workflows. Each estimate includes implementation, review, and the checks needed to meet the team's definition of done.
| Points | Backlog item | Included in this example | Why this team places it here |
|---|---|---|---|
| 1 | Explain an empty activity feed | Approved copy and an existing empty-state component; no new behavior | A small, familiar change with few affected states |
| 2 | Let workspace admins change the shared display name | Existing settings form, API and admin permission check; validation and saved/error states | A familiar path with a few behavior checks; the team's reference item |
| 3 | Filter documents by their owner | Existing filter component and API support; reset behavior and empty results | More interacting UI states than the reference, with a known data path |
| 5 | Notify a document owner when someone requests access | Existing delivery service; permission checks, notification content, duplicate handling and a link back to the request | Several existing parts must work together correctly |
| 8 | Transfer document ownership within a workspace | New transfer operation; permission changes, concurrent edits and an audit entry | A wider state transition with failure cases that need careful agreement |
| 13 | Move a folder and its documents to another workspace | Destination permissions, links, partial failures and recovery behavior | Too many connected decisions for this team to keep as one comfortable item; discuss splitting |
The infrastructure assumptions matter. A team without a notification service would be estimating additional work in the 5-point example. A team with a proven ownership-transfer operation might put that item lower.
These numbers are not a formula. Counting UI screens, endpoints, or acceptance criteria will not reproduce the estimates reliably.
How scope changes the estimate
Consider “change a workspace display name.” The table assumes an admin editing the shared label shown in settings, with an existing update endpoint and permission check.
Now change the acceptance conditions:
| Version | Scope | Illustrative estimate |
|---|---|---|
| A | Change the label shown in workspace settings; use the existing save operation | 2 |
| B | Also update invitation content and cached navigation; keep these surfaces consistent if an update only partly succeeds | 5 |
| C | The name also determines the public workspace URL; preserve old links and handle collisions | Pause to clarify, then possibly 8 or split |
Version C raises a product question before it raises a sizing question: should renaming change the URL at all? Deciding to keep a stable URL could remove much of the added work.
If one participant votes 2 while another votes 8, ask each to describe the behavior they included. Both may be reasoning consistently about different versions. Rewrite the acceptance conditions before voting again.
Pick reference stories your team remembers
Choose two or three completed items with clear boundaries. A small familiar change, a moderate workflow, and a larger but understood change give the team more useful comparisons than a single abstract number.
For each reference, keep a short note:
- What user outcome did it deliver?
- Which systems and states changed?
- What review and verification work was included?
- What assumptions made it straightforward or difficult?
Then compare new work with the closest reference. “This resembles our settings change, but adds two permission paths” gives people something concrete to challenge.
If the team has no shared delivery history, choose a well-understood item as a provisional reference. Revisit it after delivery and keep the assumptions visible. There is no need to manufacture a perfect scale before the team has learned together.
Copy this estimation note into a backlog item
Use the following as a discussion aid in your backlog or team notes:
User outcome:
Included behavior:
Explicitly excluded:
Closest completed reference:
What makes this smaller or larger:
Unknowns that could change the scope:
Decision: estimate / split / investigate
Agreed estimate, if ready:
Next clarification and owner, if needed:
Here is a filled example for the access notification item:
User outcome: the document owner learns that a workspace member has requested access and can open the request.
Included: use the existing notification service, check the recipient's permissions, link to the pending request, and avoid duplicate notifications when delivery is retried.
Excluded: reminder emails, daily digests, and automatically granting access.
Reference: our 2-point settings change uses one familiar save path. This item joins the request, permission, and delivery paths, so it involves more coordination and failure cases.
Open question: does the service already prevent duplicate delivery? The notification-service maintainer will confirm before we settle the estimate.
In the table's fictional scenario, that check confirms reusable delivery support and the team agrees on 5. Without it, the team needs to discuss the additional work before using the same number. The reference explains the comparison; it does not calculate the answer.
For the meeting sequence, use the step-by-step Planning Poker guide. It covers private voting, discussing differences, and choosing the next round's outcome.
When a number is not yet useful
Return to clarification when an unknown changes the nature of the work. “Which text should the notification use?” is a different uncertainty from “Does the destination workspace allow external users?”
For the folder-move example, the team could first agree on a smaller user outcome: move one document between workspaces the user administers. That first slice still needs clear destination permissions, preserved access rules, and safe failure handling so an interrupted move does not lose the document or expose it to the wrong people. Moving batches of documents can be a separate item. Reducing the batch size narrows the work; it does not remove the need to handle failures.
After splitting, estimate each item on its own. The new numbers do not have to add back up to 13: the team has changed the scope and learned more about the work.
Questions teams often ask
How many hours is a 3-point story?
There is no universal conversion. The examples here compare work within a fictional team. If you need a delivery forecast, use your own delivery history and current capacity, and discuss uncertainty separately from the point label.
Is every bug a 1-point item?
No. A reproducible display error with a known cause differs from intermittent data loss whose cause is still unknown. Clarify what you are estimating: the fix, an investigation, or both.
Must every team split a 13-point story?
No. Here, 13 marks work this particular team wants to examine and split. Your team's boundary depends on its references and ability to understand and deliver an item.
Bring your references into Planning Poker
Choose a few upcoming items, write their acceptance boundaries, and keep your reference stories alongside them. Use Agilo Planning Poker for the team's estimation session.
Create a Planning Poker room when the items are ready to discuss.
