Why this matters: estimation is the thing teams obsess over and the thing that is least often the real problem. Fix decomposition and scope control first, in Work Breakdown Hierarchy and Feedback and Scope Control. Then this note becomes useful. Do it in the other order and you will get beautifully estimated garbage.
A story point is not an hour
If you write “1 point = 4 hours” on a whiteboard, you have not adopted story points. You have invented a complicated way of writing hours, and you have kept every problem hours had while adding a translation step.
A story point is a relative measure. It says this Story is about twice the size of that one. It does not say how long it takes, because how long depends on who picks it up, what else they are doing, how many meetings that week holds and what they discover on day two. Relative size is stable. Duration is not.
What the team is weighing when they choose a number:
amount of work + complexity + risk + uncertainty
All four, together, in one number. That is why a Story that is technically simple but touches money calculations can be an 8, while a Story with more screens but zero risk is a 3. Hours cannot express that. Points can.
Why Fibonacci
The common scale is 1, 2, 3, 5, 8, 13, 21, sometimes modified to 1, 2, 3, 5, 8, 13, 20, 40, 100.
The reason is not numerology. It is that uncertainty grows with size, so precision must shrink with size.
You can genuinely tell the difference between a 1 and a 2. You cannot genuinely tell the difference between a 17 and an 18, and if your scale offers you 17 and 18 you will waste ten minutes arguing about it and produce a number that is no more accurate. The widening gaps in the Fibonacci scale make false precision impossible, which is the point. When the team is stuck between 8 and 13, that hesitation is real information: it means the Story has enough uncertainty that it should probably be split.
Some teams use t-shirt sizes (S, M, L, XL) for Features and Epics, and numbers only at Story level. That is a reasonable combination, because higher levels genuinely cannot be sized precisely and pretending otherwise misleads everybody.
Anchor the scale to your own work
Do not define points in the abstract. Pick reference Stories from work you have already completed, and compare everything to them.
2 points → "Add a mandatory field to the customer form with validation."
We have done this shape of work many times. Almost no unknowns.
5 points → "Add an approval step to the expense workflow."
Touches UI, API, database and permissions. Understood but not trivial.
8 points → "Integrate the new payment provider for card payments."
External dependency, error handling, webhooks, real risk.
13 points → "Multi currency revaluation at period end."
Large and genuinely uncertain. Split it or spike it before committing.
Write these on a page and use them in every estimation session. Within a few sprints the numbers become calibrated and consistent, which is all you actually need for forecasting, as explained in Velocity and Capacity.
Two consequences of this that people find surprising, and both are correct:
-
Points are not comparable between teams. Team A’s 5 has nothing to do with Team B’s 5. Comparing teams by velocity is meaningless, and using it as a performance measure is actively harmful.
-
A senior and a junior developer estimate the same Story identically. The point value describes the work, not the person. Who does it affects duration, not size.
13 is a warning sign
Treat 13 as “this is too big or too unclear for one sprint, deal with it now”. The options are: split it using the patterns in Writing User Stories, or pull the unknown out into a timeboxed spike and re estimate afterwards.
Anything above 13 should not be entering a sprint at all. It is a Feature wearing a Story’s name tag.
Planning Poker, and what it is really for
The mechanics: during refinement, the Product Owner reads a Story, the team asks questions, everyone privately picks a card from the scale, then everyone reveals at the same time.
Suppose the reveal looks like this:
Dev A: 3 Dev B: 3 Dev C: 8 Tester: 8
The wrong response is to average them into 5 and move on. That throws away the only thing of value that just happened.
The right response is to ask the 3s and the 8s to explain. Then you hear:
Dev C: “We have existing customers with data in the old format, so this needs a migration.”
Tester: “And this screen is used on Safari and on mobile, which we always underestimate.”
Dev A did not know about the migration. Nobody had thought about the browser matrix. The disagreement discovered work that would otherwise have been discovered in week two of the sprint, where it would have looked like “the estimate was wrong”.
Then you vote again, and usually everyone lands close. The final number is worth something, but the shared understanding is worth far more. Planning Poker is a requirements discovery technique that produces a number as a side effect, not a number generating ceremony.
A practical variant when you have many Stories and little time: affinity estimation. Put the Stories on a wall, sort them into columns by relative size without discussing, then assign point values to the columns and only discuss the ones people disagree about. Forty Stories in an hour instead of six.
Points on Stories, hours on Tasks
Keep these separate. In Azure DevOps’s Agile template, Story Points live on the User Story, while Original Estimate, Remaining Work and Completed Work live on Tasks and feed capacity and burndown.
flowchart TD
A["STORY: Pay using a saved card<br/>5 points"]
B["Task: Payment UI<br/>5h"]
C["Task: Payment API endpoint<br/>6h"]
D["Task: Gateway integration<br/>4h"]
E["Task: Unit and integration tests<br/>4h"]
F["Task: QA pass<br/>3h"]
A --> B
A --> C
A --> D
A --> E
A --> F
What you must not do is add the hours and derive the points. If you calculate 22 hours therefore 5.5 points, you have abandoned relative estimation and gone back to hours with extra steps.
Honestly, task hours are optional. Many good teams skip them entirely and just track how many Stories are in progress. Use them if your team finds burndown genuinely useful for spotting trouble mid sprint, skip them if filling them in is a ritual nobody reads. Field details are in Azure DevOps Setup.
Do not re estimate to reflect reality
A Story estimated at 5 that turned out to take much longer stays a 5. Do not “correct” it at the end of the sprint.
Why: points feed Velocity and Capacity, and velocity is only useful if it is measured consistently. If you inflate estimates after the fact so the numbers look right, velocity stops describing anything and your forecasting instrument is gone.
The only legitimate reason to re estimate is that the Story itself changed before work started, for example it got split, or the scope was genuinely renegotiated. And if the scope changed after work started, that is a scope event, and it belongs in the conversation described in Feedback and Scope Control, not in a quiet edit of the estimate field.
The four causes of “bad estimates”
When a sprint fails, this is the table to run through before anyone says the word estimate:
| What happened | Real cause | Where the fix is |
|---|---|---|
| The technical work was genuinely harder than anyone could know | Real uncertainty. Acceptable occasionally. | Spikes, this note |
| Nobody was sure what was actually being asked for | Refinement failure | Definition of Ready |
| The requirement grew after coding started | Scope failure | Feedback and Scope Control |
| We pulled in more than we have ever delivered | Planning failure | Velocity and Capacity |
In my experience the first row is the rarest, and it is the only one that is actually an estimation problem. The other three get misdiagnosed as estimation problems constantly, which is why teams spend months trying to estimate better and nothing improves.
Common mistakes
- Points to hours conversion. Covered above. It destroys the entire mechanism.
- The manager estimating. Only the people doing the work estimate. An estimate handed down is a deadline in disguise, and everyone knows it.
- Averaging away disagreement. The disagreement is the valuable part.
- Estimating Tasks in points. Points belong at Story level.
- Padding. If the team routinely inflates to protect itself, that is a trust problem, not an estimation problem, and it usually means velocity is being used as a performance target. Fix the management behaviour, not the numbers.
- Endless debate. If a Story takes more than about five minutes to size, it is not an estimation problem, it is an understanding problem. Stop, note the open question, and send it back to refinement.
- Estimating everything in the backlog. Only estimate what is close enough to matter. Detailed estimates for work six months out are waste.
A reasonable alternative
Some experienced teams drop points entirely and just count Stories, having first made the effort to split Stories to roughly consistent sizes. Then throughput is simply “we finish about nine Stories per sprint”, which forecasts about as well as points do.
I would not start there, because the act of estimating together is what surfaces the hidden work, and a young team needs that discovery more than it needs the number. But if your team has genuinely internalised small consistent Stories, dropping points is a legitimate simplification rather than a shortcut.