Two tools in one: rate a story's complexity, effort, and uncertainty to get a Fibonacci point suggestion — or use your team's real velocity to convert story points into an honest hour range.
The short answer: you don't calculate them, you compare them. Story points are relative — a 5 is bigger than a 3 because the team says so, calibrated against stories they've actually shipped. The longer answers depend on the situation:
Jira doesn't calculate points — it records them. Add the Story Points field to your issue type, estimate during backlog refinement (planning poker or async), and Jira aggregates them into sprint reports and velocity charts. The estimation logic — comparing against a reference story on the Fibonacci scale — happens in the team, not the tool.
Use yesterday's weather: your team's average velocity over the last 3–5 sprints is the best predictor of the next one. Adjust for known absences proportionally (a team member out half the sprint on a 5-person team ≈ 10% less capacity). Don't derive capacity from hours — that's what velocity already encodes.
Backwards from the usual question, but common when migrating a time-based backlog: divide estimated hours by your team's hours-per-point ratio (team hours per sprint ÷ velocity), then round to the nearest Fibonacci number. Treat the result as a first pass for the team to sanity-check, not a final answer.
Most teams don't point bugs (fixing them is paying back estimate debt) and time-box spikes instead of pointing them, since a spike's whole nature is unknown scope. If you do point bugs for capacity accounting, be consistent — mixing pointed and unpointed bugs quietly corrupts velocity.
Pick a well-understood, small-but-real story and call it a 2. Size everything else relative to it. Your first two or three sprints will produce a noisy velocity — that's expected. The numbers stabilize faster than teams expect once the reference stories accumulate.
Inside the sprint, no. At the commercial boundary — where someone has to sign a number — yes, carefully. The two units answer different questions for different audiences.
There's a third option many delivery teams land on: t-shirt sizing instead of story points for cross-team and pre-sales estimation, with each size carrying a three-point PERT estimate underneath. That's the model Axioplan is built on — sizes stay fast for humans, while the math produces P50/P85/P95 dates and costs a client can be shown.
Common questions about story points, velocity, and hour conversions.