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 handle Backend, Frontend and QA capacity in Jira Plans?

Gor Greyan

Hi Community,

I'm configuring Jira Plans in Jira Cloud and would like to understand how other companies handle capacity planning when multiple teams work on the same Story.

Our current hierarchy is:

Initiative

└── Epic

└── Story / Task

├── Backend Sub-task → 60h

├── Frontend Sub-task → 20h

└── QA Sub-task → 10h

We have separate Backend, Frontend, and QA teams in Plans.

Ideally, in the Timeline we'd like to see the Story's effort split by team (BE 60h / FE 20h / QA 10h), and in the Program Board we'd like those estimates to consume the corresponding team's capacity.

However, the native Team field can't be independently assigned to each subtask, and a Story/Task can only belong to one Team. So when scheduling the Story on the Program Board, its estimate only affects that one team's capacity.

We would prefer to keep our current Story/Task → BE/FE/QA Sub-task structure, since the Story represents one functional requirement.

How do other companies handle this in Jira Plans? Do you use separate BE/FE/QA Stories/Tasks, custom fields/reporting, a different hierarchy, or another approach?

I'd appreciate any real-world examples or recommendations.

Regards,
Gor

Accepted answers

All comments

James Gamble

Hola Gor,

I dug into this, and unfortunately, the limitation you're seeing is real: Jira Plans capacity is fundamentally tied to the native Team field, and a sub-task can't independently belong to a different Team than its parent. That means a single Story can't natively contribute 60h to Backend capacity, 20h to Frontend, and 10h to QA while keeping those as sub-tasks under the same Story.

The bigger planning constraint is that the plan's capacity expects work items to have a team, a sprint, and an estimate, and its capacity model is primarily built around story-level work. Atlassian explicitly says Plans assumes each team member works on one story-level work item at a time, and it recommends estimating at the story level for scheduling:

Because of that, if accurate Backend/Frontend/QA capacity inside Plans is the priority, I'd model those as separate standard-level work items rather than sub-tasks.

For example, keep the functional requirement grouped under the same Epic, but create three delivery items:

Backend implementation, Team = Backend, Estimate = 60h
Frontend implementation, Team = Frontend, Estimate = 20h
QA validation, Team = QA, Estimate = 10h

Each one can then consume the correct team's capacity in the Program Board and Timeline.

The tradeoff is exactly what you're trying to avoid: you lose the neat Story > BE/FE/QA sub-task nesting. I wouldn't try to fake that with custom Team fields, because custom fields can help with reporting and dashboards, but won't drive native Plans capacity.

A middle-ground model I've seen work is to keep one Story as the functional requirement and create the BE/FE/QA work as sibling Tasks under the same Epic, then link them back to the Story using normal work-item links such as "implements," "relates to," or dependencies where appropriate. That preserves one functional requirement while giving Plans three real capacity-bearing work items.

If you absolutely must keep the current Story > sub-task structure, I'd treat Plans as the functional planning view and use a separate reporting layer for BE/FE/QA hour distribution. A custom "Discipline" field on the sub-tasks plus Original Estimate would make the 60/20/10 split reportable in JQL, dashboards, exports, or Analytics, but it still would not consume three separate native Team capacities in Plans.

Thanks,

James

Anwesha Pan

Hi 👋🏻

Because Jira’s native Team field and capacity calculation models operate at the standard issue level (Story/Task) rather than across independent sub-tasks, teams typically adopt one of the following approaches:

1: Separate Stories under a Feature Epic (Most Common in Multi-Team Orgs)

If your Backend, Frontend, and QA teams maintain separate backlogs, sprints, or velocity/capacity trackers, the most reliable setup in Jira Plans is to promote the discipline-specific work to the Story level:

Initiative

└── Feature Epic: "User Checkout Redesign"

    ├── Story (Backend): "Checkout API & Payment Gateway" (Team: Backend, 60h)

    ├── Story (Frontend): "Checkout UI & Form Validation" (Team: Frontend, 20h)

    └── Story (QA): "End-to-End Test Plan & Regression" (Team: QA, 10h)

2: Single Story with Skills-Based Capacity (Within One Cross-Functional Team)

If your BE, FE, and QA members are organized under one cross-functional delivery team rather than strictly separate organizational teams:

Define Skills in Jira Plans (Plans Settings → Skills): Create Backend, Frontend, and QA.
Assign skills to team members based on their roles.
Assign the required skills and estimates to the sub-tasks or the parent Story (Story → BE/FE/QA Sub-tasks).

3: Hybrid — Lead Team Owns the Story, Sub-Tasks for Execution

If you must keep a single Story as the single functional requirement and do not want multiple Stories per feature:

Assign the Primary/Lead Team to the Story: Assign the Story’s Team field to the primary contributor (e.g., Backend).
Include Sub-tasks in Plan Settings: In your Plan configuration (Issue Sources & Estimation), configure sub-tasks to roll up into parent estimates.
Cross-Team Awareness via Program Board: Use issue linking (e.g., relates to or dependencies) to cross-reference tasks across teams.

⚠️ Trade-off: This will allocate the full 90h against the primary team's capacity in Plans, so the Frontend and QA teams' capacity bars won't reflect their sub-task loads automatically.

I hope this answers your question. 🙂

Thanks,
Anwesha

Gor Greyan

Hi @James Gamble,

Thanks for the detailed explanation. This confirms what I was seeing during testing.

We would strongly prefer to keep our current structure:

Epic → Story/Task → BE/FE/QA Sub-tasks

because the Story represents the functional requirement, while the subtasks represent the actual work performed by each discipline.

I tested the Program Board as well. When I assign a Team and estimate to a Story and move it into an iteration, the capacity is correctly consumed for that Team. However, as you mentioned, there doesn't seem to be a way for Jira to use the estimates from the BE/FE/QA subtasks and distribute them across three different Team capacities.

For now, it looks like we'll need to choose between keeping our existing hierarchy with separate reporting for the discipline-level estimates, or moving the capacity-bearing work to standard-level Tasks if Program Board capacity becomes a strict requirement.

Thanks again — the sibling Task approach is also an interesting option for us to consider.

Regards,
Gor

Gor Greyan

Hi @Anwesha Pan,

Thanks for providing the different approaches.

Our BE, FE and QA teams are currently configured as separate Teams in Plans, and we'd prefer to keep our existing hierarchy:

Epic → Story/Task → BE/FE/QA Sub-tasks

I tested the Team/capacity behavior, and a Story assigned to one Team correctly consumes that Team's capacity when scheduled on the Program Board. The problem is that its BE/FE/QA subtasks can't independently contribute their estimates to the three different Team capacities.

The Skills approach sounded interesting. However, from the current Atlassian documentation, I couldn't find a Jira Plans configuration that allows a single Story estimate to be split into separate BE/FE/QA capacity allocations using Skills.

Could you please share the Jira Plans documentation or an example of how you have configured Skills for this scenario? I'd be interested in testing it if it can actually distribute capacity between BE, FE, and QA while keeping the Story → Sub-task structure.

Thanks!

Regards,
Gor

Project Commander

Hi Gor,

You have read it correctly: Plans charges a Story's estimate to the one Team on the Story, and a sub-task cannot carry a Team of its own. So the choice really is the one you described. If the Program Board's team capacity has to be right, the hours have to sit on standard-level work items, one per discipline, grouped under the Epic. If the Story has to stay whole, the discipline view has to come from outside Plans.

If you keep the sub-tasks, watch the Story's own estimate. Jira's Σ Original Estimate on the Story adds the Story's estimate to its sub-tasks', so a Story estimated at 90h with 60/20/10 underneath reads 180h. Estimate the sub-tasks and leave the Story blank, never both.

Since this is close to what I work on: I build a Jira app called Project Commander, on the Atlassian Marketplace. It counts each sub-task's estimate against that sub-task's own assignee and sets each person's sprint load against their capacity after time off. It works per person and per board team, not per discipline, and it will not change what the Program Board shows.

Project Commander

Hi Gor,

Gor Greyan

Hi @Project Commander,

Thanks for the answer and the introduction to that app.

Will try to review it on the job :)
Thanks!

Regards,
Gor

Welcome!

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

Quick Links

Find more posts tagged with

jira

roadmap

plans