A story point expresses the size of a piece of work relative to other pieces of work. It deliberately has no unit. The reason is that humans are demonstrably poor at estimating absolute duration and considerably better at comparison — asking "is this bigger than that?" gets a more reliable answer than "how many days?".
What a point is supposed to combine
- Volume — how much there is to do.
- Complexity — how hard it is to reason about.
- Uncertainty — how much is unknown, which is usually the dominant term and the one most often ignored.
Why the scale is non-linear
Point scales are usually Fibonacci-ish — 1, 2, 3, 5, 8, 13 — because estimate precision degrades as size grows. The gaps encode that honestly: you can meaningfully distinguish a 1 from a 2, and you cannot meaningfully distinguish a 20 from a 21. Anything landing at 13 or above is better read as "we do not understand this yet" than as a size.
The moment points stop working
The instant anyone computes "a point is about half a day", points have become hours with extra ceremony — and worse, hours that can be negotiated. Velocity then becomes a target, estimates inflate to protect the team, and the number stops carrying information. If your organisation needs dates, produce dates directly; do not launder them through points.
What they are actually useful for
- Forecasting a backlog — total points divided by observed velocity gives a range, which is the honest form of a forecast.
- Surfacing disagreement — when two engineers estimate 2 and 13, the conversation that follows is the real value of the exercise. The number is a by-product.
- Detecting oversized work — a story that cannot be estimated should be split, and points make that visible early.
What they are not useful for
- Comparing teams. Points are calibrated within a team and mean nothing across them.
- Measuring productivity. Points measure estimated size, so rewarding them rewards estimating larger.
- Committing to dates for a single item. The distribution is wide; a forecast over many items is meaningful, a promise about one is not.
Estimating AI-assisted work
Machine assistance has compressed the volume component while leaving complexity and uncertainty broadly intact — and in code nobody has read, uncertainty has arguably risen. Teams that re-baselined by assuming everything got proportionally faster ended up with velocity that looked improved and a delivery date that did not move. Re-estimate against recent actuals rather than adjusting by a factor.
Frequently Asked Questions
Should we use points or hours?
Points for forecasting a body of work, hours only where you genuinely need a scheduled duration. Using both for the same work means you are estimating twice and trusting neither.
What does velocity actually tell us?
How many points this team completed per cycle recently, so a range for what they might complete next. It is a planning input, not a performance measure, and it breaks the moment it becomes one.
How do you estimate work nobody understands?
You do not. Timebox a spike, learn enough to estimate, then estimate. A number produced without understanding is a guess wearing a process.
References
- The Agentic Engineering Trends Report 2026 — SaaSRise
- Documenting Architecture Decisions — Michael Nygard / Cognitect
About Jishu Labs
Jishu Labs is a software development company founded in 2016. We build custom software, AI/ML systems, and full-stack web and mobile applications for clients, and we make eight AI tools for software teams.