nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Antoaneta Iskra

Hi,

I’m trying to set up a better way to plan sprints and understand how work is distributed across the team. We use company-managed projects, and I’d like to estimate user stories with story points while tracking individual tasks using hours.

During sprint planning, I want to have visibility into each person’s workload in terms of available hours, while still being able to monitor team velocity based on completed story points over time.

I’m currently migrating from Azure DevOps to Jira, so I’m still getting familiar with how Jira handles these types of planning and reporting needs.

Is there a recommended approach or built-in functionality for managing this? Currently on Jira Standard, thinking of upgrading.

Thanks!

Accepted answers

All comments

Mary from Planyway

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.

Снимок экрана 2026-07-23 в 12.06.33.png

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

Снимок экрана 2026-07-23 в 12.07.09.png

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

Anastasia Andriyanova _Teamlead_

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!

Daria Spizheva_Reliex_

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.

Alex David_epseu5

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

Alexey Pavlenko _App Developer_

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

Hempel

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.

Melika-Everview

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. image (1).png

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.

image (2).png

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. image (3).png image (4).png

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

Melika-Everview

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

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.

image (1).png

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.
image (2).png
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.
image (3).png image (4).png

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

Sean everview

Hi @Antoaneta Iskra — Sean here, founder at Everview.

Melika and I are colleagues, so you're getting one company's view across two posts rather than two independent ones. She's covered our end.

This is the Jira part, which I think is still open.

You mentioned you're on Standard and thinking about upgrading. Worth being specific about what that actually buys you, because it's the one question in the thread nobody has answered directly.

Premium gets you Plans. Plans does have capacity planning, but it operates at team level per sprint — you set a team's capacity and it warns you when work allocated to a sprint exceeds it. It is not individual capacity management.

There's no per-person availability model, no PTO handling, no "this person has 12 hours left this sprint."

So the decision splits cleanly:
- Upgrading for cross-team planning, multi-quarter roadmaps, dependency mapping and scenario comparison → Plans earns its money.
- Upgrading to get per-person hours in a sprint → it won't do that, and you'd feel misled after paying.

For genuine per-person capacity — availability calendars, allocation, PTO — that's the Marketplace, and a purpose-built app is usually cheaper than a plan upgrade for that specific need. Worth trialling one before you change plans.

One migration note since it's the thing that tends to bite: coming from ADO, the fiddly part is field mapping. Effort/Story Points and Remaining Work don't land one-to-one on Jira's Story Points plus Original Estimate, and Area Path has no clean Jira equivalent — most people end up on components or a custom field and regret whichever they picked.

Happy to compare notes if that's useful.

Mehmet A _Bloompeak_

Hi @Antoaneta Iskra

If you need a lightweight, visual and user-centric capacity planning (individual capacity planning) experience, you can try Sprint Capacity Planner for Jira developed by our team.

This app offers sprint capacity planning with an intuitive calendar interface. It enables you track user-level team availability, manage time-off and prevent over-commitment to deliver predictable sprints.

With this app, you can:

Choose between Story Points or Remaining Estimate depending on your team's workflow
Set working days and hours with story point-to-hour conversions
Manage time off (team-level and user-level)
View individual capacity per team member rather than relying on average team metrics
Easily drag work items across the Backlog, Active Sprint and Future Sprints.
Place and reorder work items anywhere on the timeline calendar to define their precise execution sequence
Spot over-allocation instantly with color-coded capacity indicators (Green: Fully utilizing available capacity, Blue: Has remaining available capacity and Red: Over-allocated)
Instantly visualize your sprint status (On Track, Behind Plan or Ahead of Plan) while monitoring Planned, Done and Target metrics in real time

For further details, you can have a look at Smart Capacity Planning and Real-Time Sprint Health in Jira article.

If you have any questions, feel free to schedule a call with us.

Hope this helps!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

workload

capacity