A story point is not an hour in disguise. Get that one idea straight and most of the confusion around estimation falls away.
If you have ever watched two engineers argue over whether a task is six hours or eight while the actual work sat untouched, you already know the problem points are meant to solve. People are bad at guessing hours and surprisingly good at judging whether one thing is bigger than another. Story points are built on the second skill and quietly ignore the first.
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 next to other work, weighing three things at once:
- Complexity. How tricky is the logic, how many moving parts?
- Uncertainty. How much do you not yet know? Unknowns are work too.
- Volume. How much sheer stuff is there, even when each piece 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 private unit: useful inside your team, meaningless the moment you compare them to anyone else's.
Why use story points instead of hours?
Because an hours estimate is a promise nobody meant to make. Say "four hours" out loud and everyone in the room hears a deadline, quietly starts holding you to it, and treats the number as a fact rather than the guess it was.
Relative sizing dodges that trap, and picks up a few quiet advantages on the way:
- It stays stable as you get faster. A team that learns its codebase still sees a 5-point story as a 5, even though it now finishes in half the time. The number describes the work, not the calendar.
- It makes trade-offs honest. When a 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 grown-up.
- It surfaces disagreement instead of burying it. Two people landing far apart on a size is not noise to be averaged away. It is a sign they are picturing different work.
How do you estimate story points?
Start with a reference story. Find something small, recently finished and thoroughly understood, and anchor it. Say you pick "add a required-field check to the signup form" and call it a 2. Now everything else gets sized against that: is this new story bigger, smaller, or about the same? That comparison is the entire technique.
A few habits keep it working:
- Size as a team. The people who will do the work do the estimating. A quick round of planning poker, everyone revealing a number at once, stops the loudest voice from setting the value.
- Treat big gaps as information. If one person says 3 and another says 13, do not split the difference to 8. Talk for two minutes about why, then re-estimate. The gap was telling you something.
- Timebox it. Estimation is not the work. A story that triggers endless debate usually needs to be split, not discussed for another ten minutes.
A simple scale to start with
Use a capped, gappy scale rather than a smooth one. The usual choice is Fibonacci-flavoured: 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 was imaginary to begin with.
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 little uncertain. Worth asking whether it should be split.
- 13: too big to plan with confidence. Split it before it enters a sprint.
Anything reaching for a 13 is 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 actually finishes in a typical sprint. After three or four sprints a rough, honest number appears: maybe 20 points. That is your velocity, and it is what you plan against.
Notice you never converted a point to an hour to get there. You measured what really happened. That is the whole difference between planning with points and planning with wishful arithmetic, and it is the discipline a good sprint planning session is built around.
The mistakes that make points useless
Most teams who "tried points and they didn't work" walked 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 thrown away everything points gave you.
- Comparing teams by velocity. Points are local. One team's 20 is not another's, and ranking teams by velocity only teaches everyone to inflate their numbers.
- Estimating a backlog nobody refined. Vague stories produce guess-shaped estimates. Points need a backlog that has been kept clear and ordered before planning starts.
Keep it light
The teams who get real value from story points treat them casually: a quick relative size, agreed together, used to shape an honest plan and then more or less forgotten. The teams who suffer are the ones who turn a two-minute habit into a measurement bureaucracy.
Your tool should nudge you toward the light version. In Scrumpy, sizing a story and dropping it into a sprint is one motion, and the points tally against your real velocity as you go, on a board the whole team can read at a glance. Keep estimation that small and it earns its place. Make it a ritual and it will quietly cost you the mornings it was supposed to save.
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.
