Agile Story Points: A Practical Guide to Estimating Without Hours
Story points are a relative unit that agile teams use to estimate work. Instead of saying “this task will take six hours”, the team says “this task is a 5 — about as big as that other thing we did last sprint”. That is the whole idea. Everything else — Fibonacci scales, velocity charts, planning poker sessions — is built on top of that one shift from absolute time to relative size.
This guide covers what story points measure, why they deliberately are not hours, which scales teams use, how to actually run a story-pointing session, and how the numbers end up in Jira. At the end there is a cheat sheet you can keep next to your backlog.
What Story Points Actually Measure
A story point bundles three things into a single number:
- Complexity — how many moving parts the work has, and how much thinking it takes
- Uncertainty — how much of the work is unknown or depends on things outside the team
- Effort — the plain amount of work, independent of who does it
The key property is that story points are relative. A 4-point story is roughly twice the size of a 2-point story — for your team, on your codebase, with your tooling. The number means nothing outside that context, and that is by design.
In practice, teams anchor the scale with a reference story: pick a small, well-understood piece of work everyone remembers — say, “add a field to the signup form” — and call it a 2. From then on, every estimate is a comparison: bigger or smaller than the reference, and by roughly how much?
Two people with very different experience levels can agree that task A is about twice the size of task B, even when they would need very different amounts of time to do either. That is why relative estimation tends to produce less arguing than time estimates — the comparison question is easier to answer honestly than “how many hours will you need?”.
Why Story Points Are Not Hours
The most common story-points mistake is quietly converting them back into time. It usually shows up as a conversion table someone pins to the wiki: 1 point = 4 hours, 2 points = 1 day, and so on.
Once that table exists, you no longer have story points — you have hours with extra steps. Every problem that story points were meant to avoid comes back: people anchor on their own speed instead of the work’s size, estimates get treated as commitments, and discussions shift from “how big is this?” to “why did it take longer than the table said?”.
The connection to time exists, but it runs through velocity: after a few sprints, you know your team finishes, say, 25–30 points per sprint. That is your planning number. It converts points to time at the team level, based on observed data — not per task, and not based on a table someone made up.
To be fair: time-based estimation is not wrong. For teams doing client billing, support work, or projects with hard external deadlines, hours can be the more honest unit. We compared both approaches in time vs. story points if you want the full trade-off. Story points earn their keep in iterative product work, where relative sizing plus measured velocity beats per-task time guesses.
Story Point Scales: Fibonacci, T-Shirt Sizes, Custom Values
Most teams use a modified Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21. The growing gaps are the point — the difference between 1 and 2 is something a team can meaningfully debate, while the difference between 20 and 21 is false precision. Bigger work carries more uncertainty, so the scale gets coarser as the numbers grow. We wrote up the full reasoning in why planning poker uses the Fibonacci series.
Two common alternatives:
- T-shirt sizes (XS, S, M, L, XL) — good for early roadmap-level sizing, where numbers would suggest accuracy nobody has. Less useful for sprint planning, because you cannot sum letters into a velocity.
- Custom values — some teams cap their scale at 8 (“anything bigger gets split”), others add a coffee-cup card for “I need a break”. Most planning poker tools, ours included, let you define your own card values.
Which scale you pick matters less than using the same one consistently. Velocity only works if a 5 this sprint means the same as a 5 last sprint.
How to Run a Story-Pointing Session
Story pointing works best as a structured group exercise, and the standard format is planning poker. The flow:
- Read the story. The product owner or facilitator reads the user story and answers clarifying questions. No numbers yet.
- Everyone estimates simultaneously. Each team member picks a card privately. Simultaneous reveal is the core mechanic — it prevents anchoring, where the first number spoken drags everyone else toward it.
- Reveal and compare. If the estimates agree, write the number down and move on. Spending ten minutes discussing whether something is a 3 or a 5 is usually wasted time.
- Discuss the outliers. If one person says 2 and another says 13, that gap is information. Usually one of them knows something the other does not — a hidden dependency, an existing helper function, a regulatory requirement. Let the outliers explain first, then revote.
- Revote until close enough. Two rounds are typical. If a story will not converge after three, it is usually too vague or too big — split it or send it back for refinement.
A few practical numbers from how we see teams use our tool: teams of 3–15 people are the typical case, with 10–20 stories per session and well under two hours total. Beyond that, estimate quality drops faster than the backlog does.
Planning poker is one of several estimation formats — affinity estimation and others scale better for very large backlogs — but for sprint-level estimation with a single team, it is the default for a reason.
Story Points in Jira
If your team works in Jira, story points live in a dedicated field, and Jira’s velocity and burndown reports aggregate them automatically once the field is populated. Three things worth knowing:
- The field may need enabling. Jira supports a “Story Points” field on issues, but depending on your template you have to add it to your screens first.
- Jira stores estimates; it does not produce them. There is no built-in voting or simultaneous-reveal mechanism — deciding what number goes in the field happens outside Jira’s core feature set, either through a paid Marketplace plugin or a standalone tool in a second browser tab. We compared both workflows honestly — including when the plugin is the better choice — in planning poker for Jira without the plugin.
- Jira accepts any number; your team should not. The field takes arbitrary decimals. Stick to your agreed scale anyway — a backlog with 3.5s and 6es in it means someone is doing time conversion in their head.
The short version: story points in Jira are an output. The estimation itself — the discussion, the reveal, the revote — is what this whole article is about, and it happens in the conversation, not in the field.
Story Points Cheat Sheet
A reference table for the modified Fibonacci scale. The descriptions are a starting point — your team’s reference stories will sharpen them over time.
| Points | Rough meaning | Typical action |
|---|---|---|
| 1 | Trivial. Well understood, tiny change. | Just do it. |
| 2 | Small. Known territory, no surprises expected. | Good reference-story size. |
| 3 | Medium. Some thinking required, minor unknowns. | Standard sprint fare. |
| 5 | Large. Several moving parts or one real unknown. | Fine, but check it can finish in a sprint. |
| 8 | Big. Multiple unknowns, touches several areas. | Consider splitting. |
| 13 | Very big. Significant uncertainty. | Split it unless there is a hard reason not to. |
| 21 | Too big to estimate honestly. | Always split. This is an epic wearing a story costume. |
Common Mistakes (and Honest Limits)
The mistakes we see most often:
- Converting points to hours per task. Covered above — it silently deletes the benefit of the whole system.
- Averaging instead of discussing. If votes are 2, 3, 5, and 13, the answer is not 5.75. The 13 has a reason; find it.
- Comparing velocity across teams. Team A’s 30 points and team B’s 30 points have nothing to do with each other. Cross-team velocity comparison punishes honest estimators and rewards inflation.
- Using points as a performance metric. The moment “points delivered” appears in performance reviews, estimates inflate and the data becomes worthless. Velocity is a planning input, not a productivity score.
And the honest limits: story points do not fix unclear requirements, an unstable team, or a product owner who keeps reshuffling priorities mid-sprint — they just make those problems visible faster, which is uncomfortable but useful. For very small teams (two or three people) that already share full context, formal pointing can be more ceremony than it is worth; a quick “small, medium, or scary?” conversation sometimes does the same job. And the first few sprints of velocity data will be noisy — that is normal, not a sign you are doing it wrong.
FAQ
What are story points in agile? A relative unit for estimating work. Instead of estimating time, the team rates each story’s size — complexity, uncertainty, and effort combined — against work they have done before. The numbers are team-specific and only meaningful within that team.
How many hours is one story point? There is no fixed conversion, on purpose. The link between points and time emerges at team level through velocity — the points your team actually completes per sprint, measured over several sprints. Any per-task conversion table turns story points back into hours and removes their benefit.
What scale should we use for story points? The modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) is the most common choice, because the growing gaps match the growing uncertainty of bigger work. T-shirt sizes work for rough roadmap sizing. Consistency matters more than the specific scale.
Do story points work outside software teams? Yes — the mechanism is generic. Any team estimating work with built-in uncertainty (marketing campaigns, content production, hardware prototyping) can size relatively and track a velocity. The reference-story trick works the same way.
If you want to try story pointing with your team, open a free planning poker room — no signup, share the link, start voting. The free version shows ads; Premium ($40/year for the whole team) removes them. One sprint planning session is enough to see whether relative estimation fits your team.