Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
For the next sprint, Jira displays the total number of story points in the backlog, calling it "Estimate.". This number leaves out tasks, which are estimated in hours, not story points. This makes it difficult to get a sense of how much load is being increased as tasks are being added to the sprint.
One approach is to wrap every task inside some story. Is there a better approach?
Mixing relative and absolute estimation is problematic and difficult. If you were going to use relative estimation (story pointing is one form of relative estimation, while hours is absolute estimation) I would only use that. There will be some things that don't get points (spikes, bugs, etc) but usually this is a small enough percentage of the work in the sprint that it isn't particularly impactful. In this approach, we use past velocity to plan capacity instead of hours available.
Now, nothing about Scrum says you have to use relative estimation. A lot of the industry has moved away from that because studies have consistently shown absolute estimation to be wildly inaccurate in many contexts. This may not apply to you and if your context lends itself well to absolute estimation, nothing should stop you from using that, but then I would use just that. In Jira, it looks like you can change using points or Original Time Estimate in the board settings: https://confluence.atlassian.com/jirasoftwarecloud/configuring-estimation-and-tracking-764478030.html
If you have already started the sprint - i.e. its an active sprint and you want to see the 'burn-down chart' in hour instead of story points, then you can go to the settings of the board in Jira you can change the burn-down to look at hours instead of story points.
