+1

Please remember that if you want this feature in Jira Cloud, you need to vote here: https://jira.atlassian.com/browse/JSWCLOUD-5797

This is a very important feature in Jira that is missing!

+1 without this i find the board to be cluttered. also value of creating sub tasks is reduced significantly.

In case you see very low adoption of sub tasks – this must be one of the key reason!

+1

This is a very important feature for the marketing industry!

I understand the SCRUM purist mentality on this but Jira is used by more than just software engineering teams.  If a team using Jira has another planning approach for stories or any issue type that has subtasks for that matter, the system should allow those subtasks to either inherit the parents sprint, OR allow for subtasks to have their own sprints.  I cannot believe this 'suggestion' has been open for 10 years...

This self-imposed limitation in Jira is ridiculous.

Whether or not some feature or capability aligns with the scrum ideology, or any ideology for that matter, should not be the basis for allowing or restricting it. The question is, can it help people do what needs to be done given their particular situation.

Without even discussing the justification for including subtasks directly in sprints, it shouldn't be fundamentally restricted. Developers do not know every scenario a team may find themselves in or when a feature may be helpful / better than the prescribed methodology.

Since many people want this feature, and since this feature comes with relatively practical and relatable use cases, and since deliberately restricting this feature would be for the sake of ideological conformity...  it should have remained optional.

Jira can go ahead and throw up a warning any time you deviate from scrum methodology by enabling a feature or it can offer the prescribed method as an alternative, allowing the user to then happily click the button labeled, "Cool. I don't actually care but thanks. I'll take my chances."

Allow the tool to be as flexible as possible where it's easy enough to allow it. It may not align with the tool's original intent, but it may meet unforeseen needs or open the tool up for more novel uses, widening its market appeal.

All that said, my use case for subtasks seems pretty similar to all the other folks who ask for it. Alternatives like those proposed here seem very problematic.

Ultimately, we want a single Jira issue / ticket to represent a single deliverable (e.g. Create a an Inventory PowerBI Report for the Operations Department). 

We want subtasks to represent a chunk of work for that deliverable which can be accomplished in a single sprint (e.g. Gather requirements and research potential solutions).

It's uncomplicated and intuitive. Why subtasks are assumed to all be tiny little steps not worth pointing or tracking in a sprint is bizarre. Even simple steps can turn into more than we assumed they would be during a sprint, giving need to slap points on it and see it in the sprint so our managers know where our time is going.

Yes, we could use epics to represent each individual deliverable. The tickets within that epic would then be considered the measurable subtasks for sprint purposes. The problem here, though, is that...

(1) We want to use Epics to represent larger scale initiatives or groups of related deliverables (e.g. Replace SSRS Reporting System Company-Wide). More than just preference, large scale initiatives like these show up quite naturally on our Jira Road Map. It gives us broad oversight into all the initiatives we have planned and currently in progress. It allows us to conveniently manage the start and end date of large scale initiatives, see how they fit into our sprints, and see the individual deliverables (i.e. Issues) involved in each and where they fall into the initiative's timeline.

Suggesting that we upgrade to the more costly version of Jira or use an addon to manage large scale initiatives (i.e. essentially create epics of epics), seems a very heavy-handed and costly solution, just to avoid breaking scrum ideals, putting points on subtasks and making them visible in sprints.

(2) If we were to make an epic for every single deliverable in our backlog, that would be 100 epics right there. Our Jira Road Map would be unbelievably large, giving no broad and automated oversight into the actual initiatives each deliverable was for. We could not use the road map to actually... road map the large scale projects we aim to complete in the coming months. The road map would become nothing more than a view of the backlog / planned sprints in the form of a morbidly obese calendar.

(3) Managing the relationship between individual Issues and their Epics is more work and less intuitive than simply clicking the "Create Subtask" button on an Issue. The relationship is immediately established by clicking that button on an Issue. Moreover, you can easily arrange the order of subtasks on the Issue by clicking and dragging them. I don't believe you can do that with the Issues displayed in an Epic. They are stuck and get cluttered really fast.

Yes, we could use a dozen other workarounds, but we lose intuitive usage, ease of management, and the benefit of built-in automated tools like the Road Map.

The scenario we're in over here does not seem unusual to me, so I'm puzzled as to why it's difficult for some to relate to the problem. You either use epics to track large scale initiatives for broad department oversight, losing the ability to break up individual deliverables into sprint-managed subtasks, or you turn the road map into a vomit of disconnected deliverables, but gaining the ability to treat each Issue like a pointed, sprint manageable subtask of the deliverable. 

Linking several Issues together is unwieldy and not something that gives clear oversight on what Issues are deliverables and part of an epic and which are just subtasks.

If we're missing something obvious here, I'm not above admitting I'm a moron, so have at it.

+1

+1

+1

A finished User Story represents some value for the customer.

In cases when that value can not be achieved unless both UI and API systems are changed, it makes sense to split sub-tasks of the User Story to different sprints.

Instead of committing to completing the whole User Story in the sprint, we can correctly adjust the workload of the sprint by adding some sub-tasks of said User Story. For example, sub-tasks that involve the API first, then sub-tasks involving UI would be done in a later.