How do you manage team capacity in Jira using story points and time estimates?

Hi Antoaneta,

If you’re coming from Azure DevOps, the main adjustment is that Jira separates velocity tracking from capacity planning a bit more.

Here's what I recommend:

• Use story points on user stories to track team velocity over time. Jira’s Velocity Chart and Sprint Reports are designed for this.
• Use time estimates on tasks/subtasks when you need to understand actual workload — for example, whether someone has enough capacity to take on more work during a sprint.

The tricky part is getting a clear picture of that capacity before the sprint starts. Jira shows what’s planned, but it doesn’t always make it easy to see how work is distributed across the team or whether someone is overloaded.

That’s where Planyway can help. It gives you a visual workload view on top of your Jira issues, so during sprint planning you can see each person’s available capacity, planned hours, and workload balance.

Workload is calculated based on set capacity, scheduled time, and estimation that can also be linked to Jira issues.

You can adjust assignments, move work around, and reschedule issues directly from the timeline while keeping everything synced with Jira.

A setup that works well is:

• Jira → backlog management, story points, sprint execution, and velocity tracking
• Planyway → sprint planning, capacity planning, and workload balancing

Hi Antoaneta Iskra — coming from Azure DevOps, the split you're describing is the right
instinct, and the native setup is covered well above: Story Points on the story for
velocity, Original/Remaining Estimate on sub-tasks for hours, and the board's Estimation
statistic set to Story Points so the two don't fight.

Two things worth being precise about, since they affect your upgrade decision:

Sub-task hours do roll up to the parent — that's the time tracking panel's
include-sub-tasks behaviour, plus the Σ Original/Remaining Estimate columns in the issue
navigator. Story points don't roll up, so keep those on the story. What has no native
aggregate is a per-person total across a sprint. The Workload Pie Chart Report is the
closest thing on Standard: Statistic Type = Assignee, Time Field = Current Estimate,
against a filter like `sprint in openSprints() AND statusCategory != Done`.

And on Premium — Plans does capacity planning, but at team level per sprint with an
overbooked warning. It isn't individual capacity management, so it won't answer "how many
hours does this person have left."

I'm on the team at Everview.

Since you asked specifically about hours: the effort field is set per team and takes any
numeric Jira field. Numbers pass through as-is, so if you map Original Estimate, the
workload, capacity, and per-person figures all read in hours rather than points.

Where you're deliberately running two systems at once — story points on stories, a
time-boxed sprint underneath — you set the conversion once and the two axes reconcile.

The part I'd argue for regardless of tooling: capacity only means something once
availability is in it. Marking three days off for one person here drops team bandwidth
23 → 22 and delivery confidence 88% → 84%, and the sprint's day bars show where the gap
falls. A sprint that looks overloaded is sometimes just someone's vacation.

One more thing given where you are: we read both Jira and Azure DevOps, and teams on
different providers appear on the same canvas at once — so during a phased migration your
not-yet-moved ADO teams sit next to your Jira teams. It reads your full history on
connect, so you're not starting from an empty forecast either.

Free to try on the Marketplace if you want to poke at it.

Hi Antoaneta Iskra — coming from Azure DevOps, the split you're describing is the right
instinct, and the native setup is covered well above: Story Points on the story for
velocity, Original/Remaining Estimate on sub-tasks for hours, and the board's Estimation
statistic set to Story Points so the two don't fight.

Two things worth being precise about, since they affect your upgrade decision:

Sub-task hours do roll up to the parent — that's the time tracking panel's
include-sub-tasks behaviour, plus the Σ Original/Remaining Estimate columns in the issue
navigator. Story points don't roll up, so keep those on the story. What has no native
aggregate is a per-person total across a sprint. The Workload Pie Chart Report is the
closest thing on Standard: Statistic Type = Assignee, Time Field = Current Estimate,
against a filter like `sprint in openSprints() AND statusCategory != Done`.

And on Premium — Plans does capacity planning, but at *team* level per sprint with an
overbooked warning. It isn't individual capacity management, so it won't answer "how many
hours does this person have left."

I'm on the team at Everview.

Since you asked specifically about hours: the effort field is set per team and takes any
numeric Jira field. Numbers pass through as-is, so if you map Original Estimate, the
workload, capacity, and per-person figures all read in hours rather than points. 

Where you're deliberately running two systems at once — story points on stories, a
time-boxed sprint underneath — you set the conversion once and the two axes  reconcile.     

The part I'd argue for regardless of tooling: capacity only means something once
availability is in it. Marking three days off for one person here drops team bandwidth
23 → 22 and delivery confidence 88% → 84%, and the sprint's day bars show where the gap
falls. A sprint that looks overloaded is sometimes just someone's vacation.

One more thing given where you are: we read both Jira and Azure DevOps, and teams on
different providers appear on the same canvas at once — so during a phased migration your
not-yet-moved ADO teams sit next to your Jira teams. It reads your full history on
connect, so you're not starting from an empty forecast either.

Free to try on the Marketplace if you want to poke at it — Everview.Ai

Hi @Antoaneta Iskra - The split you're describing — story points for velocity, hours for per-person capacity — is right, and the gap in Jira Standard is real.

Since Planyway and TeamTime have both been mentioned, Tempo Capacity Planner is worth adding. The Resource Planning view shows each team member's available and planned hours in a days or weeks view; you can plan at the issue level directly from the timeline, pulling remaining estimates from Jira. A setup that works well: story points on stories for velocity tracking, Tempo Timesheets for actuals on tasks, Tempo Capacity Planner for forward-looking resource planning.

Disclosure: I work for the team behind Tempo.

Hi @Antoaneta Iskra ,

During sprint planning, I want to have visibility into each person’s workload in terms of available hours

For detailed capacity planning, I would recommend the Jira Premium plan which comes with Jira Plans. Jira Plans has team and individual capacity planning.

while still being able to monitor team velocity based on completed story points over time.

For that, the built-in the Sprint Report and Velocity Report would be a good fit. However, they have limitations, you can't:

• Track:
  • Data across months, quarters, half-years or years. 
  • Several teams (including those ones sharing the same project) at once.
  • Capacity, allocation
  • added and removed scopes, as well as other metrics reliably. Or create your own custom metrics using JQL for tracking.
  • Trends and average metrics across periods.
• Conduct Quantifiable retrospectives.
• And many more.

If you need a tool without those limitations, you could install the app I developed - Multi-team Scrum Metrics & Retrospectives.

3 boards/teams in the same view, 1 period selected for analysis:

3 boards/teams in the same view, all periods are clicked for average metrics and dynamics:

Best regards,
Alexey

Hey Antoaneta, you can get most of this natively before reaching for a paid app.

The usual setup is two different fields for two different jobs:

- Story Points on the story or parent, for velocity and longer-term planning.

- Original Estimate and Remaining Estimate (time tracking) on the sub-tasks, for the hour-level tracking.

Set your board's Estimation statistic to Story Points, and let the time tracking fields handle hours separately, so the two don't fight each other.

For per-person workload during planning, a few free built-ins:

- Backlog view, grouped by Assignee, to see how work is spread.

- The Sprint Report and Burndown for the committed sprint.

- The Workload Pie Chart gadget on a dashboard, pointed at a sprint filter and grouped by assignee, for a quick per-person hours view.

One honest caveat: Jira does not auto roll up sub-task estimates to the parent, so if you want summed hours per story or per person you'll need a dashboard gadget or a filter to add it up. That's the main thing that trips up folks coming from Azure DevOps. If you do move to Premium later, Plans (Advanced Roadmaps) has a proper capacity view that does this for you.

Hope that helps.

Alex

Hi @Antoaneta Iskra and welocme! This is a common setup, and it's basically what ActivityTimeline (a Jira app we build) is designed for.

• Mixing story points and hours: Keep story points on your stories for velocity, hours on sub-tasks. AT lets you set a Story Point → Hours conversion factor (global or per-project) so both feed into the same workload calculation without changing how you estimate in Jira.

• Per-person workload during sprint planning: Each person's available hours (capacity) are set individually and shown against what's assigned to them (workload) right on the Planner — so you see who has room before the sprint starts.
• Sprints: ActivityTimeline can auto-place issues on timelines using Jira sprint start/end dates, no manual scheduling.
• Velocity: Worklogs (actual time) are tracked separately from planned workload, so you get planned-vs-actual reporting across sprints for velocity trends.

One note: some features (like Workload Schemes for bulk setups) need Jira Standard or above, so worth checking against your plan. Happy to help map your ADO setup over — support@reliex.com.

Hi @Antoaneta Iskra,

Transitioning from Azure DevOps to Jira often comes with this exact challenge!

In Jira Standard, you can natively achieve this split by setting Story Points on parent Stories (for velocity) and using Time Tracking (Original/Remaining Estimate) on sub-tasks assigned to individuals. However, Jira Standard doesn't automatically roll up sub-task time estimates to give you a clear total effort view per Sprint without manual tracking.

Since you mentioned considering an upgrade: Jira Premium introduces Plans (formerly Advanced Roadmaps), which includes built-in capacity and workload management for teams and individuals in both hours and points.

However, if upgrading your entire Jira plan feels like overkill just to manage estimates and actuals across your hierarchy, a targeted app can bridge the gap.

(Disclaimer: I'm part of the Teamlead team behind TeamTime)

If your main pain point is tracking estimated vs. actual hours across tasks and sprints alongside Story Points, you might want to check out TeamTime. It automatically rolls up time estimates and worklogs across sub-tasks, stories, and sprint containers, giving you a clear view of remaining effort and progress ratios without messy spreadsheets.

Hope this helps you set up a smooth planning process!