Story points are one of those ideas that sound complicated and turn out to be simple, as long as nobody tries to make them clever. If you have ever sat in an estimation meeting watching two engineers argue about whether something is six hours or eight, you already understand the problem points are meant to solve.
Here is the plain version, with no ceremony.
What are story points?
A story point is a relative measure of how much effort a piece of work will take. Not how long in hours, but how big it feels compared to other work, taking in three things at once:
- Complexity. How tricky is the logic, and how many moving parts are involved?
- Uncertainty. How much do you not yet know? Unknowns are work too.
- Volume. How much sheer stuff is there to do, even if each bit is easy?
A story worth 8 points is roughly twice the effort of one worth 4. That is the whole concept. Points are your team's own unit, useful inside your team and meaningless when compared to anyone else's.
Why use story points instead of hours?
Because people are genuinely bad at estimating hours, and reasonably good at comparing sizes. Ask someone how many hours a task will take and you will get a confident number that turns out to be wrong. Ask whether this task is bigger than that one and they will usually be right.
Points lean on the judgement humans are actually good at. They have a few other quiet advantages:
- They stay stable as you get faster. An hours estimate implies a promise about the clock. A team that gets better at its codebase still sees a 5-point story as a 5, even though it now finishes faster. The point value describes the work, not the calendar.
- They defuse the false promise. Once you say "four hours," everyone hears a deadline. "Three points" carries the size without pretending to predict the exact minute you will be done.
- They make relative trade-offs obvious. When the product owner can see that one feature is 13 points and a near-identical alternative is 3, the conversation about scope gets a lot more honest.
How do you estimate story points?
Start with a reference story. Find something small, recently finished and well understood, and anchor it: call it a 2 or a 3. Everything else gets sized against that anchor. Is this new story bigger, smaller, or about the same as the reference? That comparison is the entire technique.
A few habits make it work:
- Estimate as a team, not as individuals. The people who will do the work do the sizing. A quick round of planning poker, where everyone reveals a number at once, surfaces disagreement instead of letting the loudest voice set the number.
- Treat big gaps as information. If one person says 3 and another says 13, do not average to 8. The gap means you understand the story differently. Talk for two minutes, then re-estimate.
- Timebox it. Estimation is not the work. If a story is causing endless debate, that is usually a sign it needs to be split, not discussed for another ten minutes.
A simple scale to start with
Use a capped, slightly gappy scale rather than a continuous one. The classic choice is a Fibonacci-style sequence: 1, 2, 3, 5, 8, 13. The gaps are deliberate. They stop you agonising over whether something is a 6 or a 7 when that precision is imaginary anyway.
Give the numbers a rough shared meaning:
- 1 to 2: small and well understood, no surprises expected.
- 3 to 5: a normal story, some thought required but a clear path.
- 8: large or a bit uncertain. Worth asking whether it should be split.
- 13: too big to plan confidently. Split it before it enters a sprint.
Anything that wants to be a 13 is really a signal, not an estimate. It is telling you the story is hiding several smaller stories inside it.
How points turn into a plan
On their own, points are just sizes. They become useful when you watch how many your team completes in a typical sprint. After three or four sprints you will see a rough, honest number: maybe 20 points a sprint. That number is your velocity, and it is what you plan against.
Notice that you never converted a point to an hour to get there. You measured what actually happened. That is the difference between planning with points and planning with wishful arithmetic. When it is time to commit, you pull stories up to your honest velocity and stop, which is exactly the discipline a good sprint planning session is built around.
The mistakes that make points useless
Most teams that "tried points and they didn't work" fell into one of these:
- Converting points back to hours. The moment you publish a "1 point = 4 hours" table, you have rebuilt hourly estimates with extra steps and lost everything points gave you.
- Comparing teams by velocity. Points are local. One team's 20 is not another team's 20, and ranking teams by velocity just teaches everyone to inflate their numbers.
- Chasing precision. Endless debate about 5 versus 8 is wasted effort. The estimate is a rough size to enable a decision, not a measurement.
- Estimating a backlog nobody refined. If stories are vague, every estimate is a guess. Points need a backlog that has been kept clear and ordered before planning starts.
Keep it light
The teams who get value from story points are the ones who treat them casually: a quick relative size, agreed together, used to shape a realistic plan, and never mistaken for a contract. The teams who suffer are the ones who turn a lightweight tool into a measurement bureaucracy.
Your tool should encourage the light version. In Scrumpy, sizing a story, dropping it into a sprint and watching the points add up against your velocity all happen on one simple scrum board, so estimation stays a two-minute habit instead of a meeting. Try Scrumpy free at a flat $9 per editor per month, invite the whole team to estimate together, and let your view-only stakeholders watch the plan take shape for nothing.
Frequently asked questions
What are story points?
Story points are a relative measure of how much effort a piece of work will take, accounting for complexity, uncertainty and volume rather than raw hours. A story worth 8 points is roughly twice as much work as one worth 4. They are a team's own unit, not a universal one.
Why use story points instead of hours?
People are bad at estimating hours but reasonably good at judging whether one task is bigger than another. Points lean on that relative judgement, stay stable as the team gets faster, and avoid the false precision of an hours estimate that everyone treats as a promise.
How do you estimate story points?
Pick a small, well-understood story as a reference and call it a 2 or a 3. Then size everything else against it: is this story bigger, smaller or about the same? Estimate as a team, discuss any wide disagreements, and use a capped scale so nothing balloons past 13.
How many hours is a story point?
There is no fixed conversion, and trying to set one defeats the purpose. A point is a unit of relative size for one team. Over a few sprints you will see roughly how many points your team completes, and that velocity, not an hours formula, is what you plan with.