Best way to structure Epic → per-platform work when subtasks can't be split across sprints?

[Kristina Svobodina]

Hi everyone,

I'm looking for advice on structuring a recurring pattern in our workflow: features that need to be implemented across multiple platforms (iOS, Android, Web, etc.), where the work items are often nearly identical across platforms.

Our current structure:

• Epic = a feature
• Child task under the Epic = one per platform
• Subtasks under each child task = the actual implementation steps

Why I like this structure:
Grouping by platform this way makes it very easy to see, at a glance, which tasks are done/in progress on each platform, and to compare progress across platforms side by side- much clearer than having all tasks flattened directly under the Epic as one big list.

The problem:
The problem is within a single platform tasks: when a platform's feature work takes more than one sprint, we can't split its subtasks across sprints - they all inherit the sprint of their parent child task. So even though the child task could conceptually span multiple sprints, all its subtasks are stuck together in one sprint, making it impossible to actually use sprint planning at the subtask level for that platform's work.

So we're stuck between:

1. Flattening everything into direct issues under the Epic - loses the clear per-platform grouping/comparison we rely on.
2. Keeping the child task/subtask hierarchy: but then all of a platform's subtasks are forced into a single sprint, even when the work genuinely needs to span multiple sprints.

Question:
Is there a better way to structure this that preserves the per-platform grouping/comparison view, while still allowing the subtasks within a single platform's work to be planned into different sprints when needed?

I understand issue links could technically connect the work, but that loses the real parent-child hierarchy -the nesting, progress rollup, and clear grouping. I'm hoping for a solution that keeps that structural clarity while also solving the sprint-planning limitation.

Thanks in advance!

[Melika-Everview]

@Tomislav Tobijas  and @Habib__Plugio__  are right on the core constraint subtasks inheriting their parent's sprint is a hard Jira limitation, and the structural fixes they described (shift the hierarchy up on Premium, or flatten and group by component) are the real native answers. Worth reading their options first.

The honest tension in both, though, is the one you already named: the structural fix that frees up sprint planning is exactly the one that costs you the clean per-platform grouping you rely on. You're being asked to trade one for the other.

That trade-off is the gap we work on at Everview (disclosure: I'm on the team). It sits on top of Jira.
Jira stays your source of record, nothing migrated and reads your work onto one live canvas where two things are true at once:

• A platform's work isn't locked to a single sprint. You can push items forward into later sprints as the work genuinely spans them (the thing Jira won't let you do at the subtask level) without flattening your structure to get it.
• The per-platform picture stays intact. iOS, Android, and Web sit side by side, each showing live progress read straight from the actual Jira issues (every card is a real issue, carrying its real key), so the at-a-glance "which platform is where" view survives the exact thing flattening would cost you.

One honest caveat: it won't magically make a Jira subtask hold its own sprint — that limitation is Atlassian's. What it does is give you a planning-and-progress surface where the per-platform grouping and the multi-sprint spread coexist, instead of you choosing between them.

The sandbox is open if you want to see whether it fits your structure (no signup) and it's on the Atlassian Marketplace if you'd rather try it on your own instance: Everview.ai

[Tomislav Tobijas]

Hi @Kristina Svobodina ,

The easiest solution is to upgrade to Premium. But, as that isn't always a possible solution 👀, you could maybe consider restructuring the levels you already have:

• Epic (Level 1): Use this for your platform-specific grouping (e.g., "Feature X - iOS"). This keeps your "per-platform" view intact in the Epic Panel and Timeline.

• Stories/Tasks (Level 0): Use these for your implementation steps. Since these are now standard issues, they can be assigned to different sprints independently of the Epic.

• Initiative (Optional): Since you cannot add a level above Epic on Standard, use Labels or a Component (e.g., "Feature-X") to group your platform-specific Epics for a high-level view.

We've implemented something similar in one of our client environments due to a plan-related restriction. 

You could also consider leaving Epic level as-is and then creating new work types for level 0 (everything below Epic) to group specific things; or just use Labels and Components as suggested. 🤔

There are also these two feature requests related to assigning separate sprints to sub-tasks:

• JRACLOUD-90857: Sub-Tasks without main-task in the same or any sprint 
• JRACLOUD-98079: Allow subtasks to be independently assigned to sprints without requiring parent/ sibling inclusion 

Hope this helps.

Cheers,
Tobi

[Habib__Plugio__]

Hi @Kristina Svobodina ,

Unfortunately what you're hitting is a hard Jira limitation: subtasks can't be assigned to a sprint independently — they always follow their parent. There's no setting or workaround at the subtask level, so the fix has to be structural. Two realistic options:

Option 1 — shift the whole hierarchy up one level (needs Jira Premium):
With Advanced Roadmaps you can create a custom hierarchy level above Epic (e.g. "Feature"). Then:

- Feature = the feature
- Epic = one per platform (iOS, Android, Web)
- Tasks/Stories under each Epic = the implementation steps
This is exactly your current structure, just moved up a level — you keep true parent-child nesting, per-platform grouping and progress rollup, but the implementation steps are now real issues, so each one can be planned into whatever sprint it needs. If you're on Premium, this is the cleanest answer.

Option 2 — flatten, and move the platform grouping into a field (works on any plan):
Put the implementation tasks directly under the Epic and set the platform as a Component (or label) on each. Sprint planning works per task, and you rebuild the per-platform comparison view with:

- board swimlanes or quick filters by component, and/or
- a dashboard gadget grouping the Epic's issues by component.
You lose grouping-by-parent, but grouping-by-field gives you the same "which platform is where" picture, and it's actually more flexible (a task spanning two platforms just gets two components).

One extra note if you go with Option 2: the thing you'd miss most is the at-a-glance per-platform progress inside the Epic itself. That part can be recovered with apps — for example Plugio Panels (disclosure: I work for Plugio) lets you add progress bars to the epic's issue view, each scoped by JQL — e.g. one bar for parent = epic AND component = iOS, one for Android, one for Web — aggregated by issue count or story points. So you get the side-by-side platform comparison back without needing the intermediate parent task.

Hope that helps!