Skip to content
Menu
HelpJira story points to hours: Jira has no conversion

Jira story points to hours: Jira has no conversion

Checked on 6 November 2026 against Atlassian’s documentation and Atlassian Community.

New to estimates in Jira? Start with Add story points and Add time estimates.

Your team estimates in story points, and someone asks what that is in hours or days. Or the reverse: the work is estimated in hours, and the board wants points. On Atlassian Community it reads “we are estimating the issues using story points and Tracking using hours. So we would like to know is there any setting in JIRA Agile saying that a story point is equal to a number of hours” (Community, February 2016). This page says what Jira does, why a fixed ratio misleads, and how to see both figures for one epic.

What Jira does by itself

  • It has no conversion. The accepted answer to that question: “In principle a story point should never be expressed in hours. It’s a relative measuring instrument.” The next reply: “there is absolutely no equivalence anywhere in JIRA” (Community). An asker in July 2023 wanted the original estimate filled in from the points, 1 point as 2h, and was told to estimate in the original estimate field instead (Community, July 2023).
  • They are two separate fields. Story points are “Story Points” in company-managed spaces and “Story point estimate” in team-managed spaces (Atlassian’s smart values reference). Time is Original estimate, Time spent and Remaining estimate. A company-managed Scrum board picks one as its estimation method and can add time tracking as a second; a team-managed space picks story points or time (Atlassian).
  • Points are not a time. Atlassian’s guide says story points “consider complexity, risk, and the amount of work, rather than specific hours or days”, and that each team estimates on a slightly different scale, so their velocity “will naturally be different” (Atlassian, Story points and estimation).

Why a fixed ratio misleads

Say a team fixes 1 point at 4 hours. Every 3-point story is then 12 hours, whatever the story involves, and the ratio holds for that team only, since each team’s scale differs (Atlassian’s guide, above). Another Community answer says why it fails: “Story points are not useful as a proxy for time, they are intended to be a way to size stories against each other so you can work out what the team can get done in a sprint” (Community, July 2023). Its advice for a team that wants hours is to estimate in the Original estimate field: “With the estimate, your people can log work (actual work done), or amend the estimate without losing sight of what they originally put in.”

Both on one epic, in Jira

  • On a work item, story points and the time estimate are separate fields, each with its own value.
  • Σ fields add a work item’s sub-tasks to its time tracking values and go no further: “Time estimate and time tracking currently roll-up to 1 level up based on the hierarchy. The roll-up doesn’t go beyond that” (JRACLOUD-70150, Atlassian, June 2025). They are time only, and there is no Σ for story points: the request to sum them for an epic is marked “Not Being Considered” (JRACLOUD-90636, September 2024).
  • The Epic report lists an epic’s complete, incomplete and unestimated work by the board’s estimation statistic, story points by default. It is for company-managed Scrum boards (Atlassian).
  • Plans (Premium and Enterprise) rolls estimates up through every level, in story points, hours or days, inside the plan (Atlassian).

An Automation rule can write one total into a field, one level and one field at a time; see Sum story points to the epic in Jira Cloud. Doing both fields means two rules for each level.

With Sumline

Sumline is our app. It does not convert one to the other, and does not guess a ratio. It adds up each field as Jira has it and shows the results side by side:

  • On the epic, the panel shows story points done of total, original estimate done of total, time logged and time remaining, across every level below it, with children in other spaces included.
  • Two percentages: % complete by estimate (story points, or time where no story points are counted) and % complete by work item count.
  • What does not match is named. Where % complete is by story points, each branch that carries hours and no story points is named; where it is by time, each branch with story points and no time. Neither is counted as 0 or turned into the other unit.
  • The same figures in a table per space or across spaces, and in Excel and CSV downloads.

Sumline only reads, so its totals are not a Jira field: you cannot search them with JQL or use them in an Automation rule. How each number is worked out is in How the numbers are calculated. For the epic’s own estimate and the time under it, see Jira epic estimate: original and remaining.

The Sumline panel on an epic: “12 child work items across 2 levels” with “Updated 1 min ago” and Recalculate at its right, Story points 10 / 28, Original estimate 7h / 12h, Logged 8h, Remaining 4h, progress by story points (36%) and by work item count (50%), one amber box “Check these work items” naming WEB-15 with no estimate, the child table with its Warnings column, and Open in Sumline.
The Sumline panel on the epic WEB-1: story points 10 of 28 and original estimate 7h of 12h, with 8h logged and 4h remaining, side by side.

Try it on your own epics

Free for up to 10 users, then billed per user by Atlassian.