Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,459,764
Community Members
 
Community Events
176
Community Groups

How to assign subtask to specific sprint

Hello,

There is a need here to leave a task without sprint but assigning one of the subtask to specific sprint. The problem we having is how to add sprint field to subtask. And second, it is a proper way to use Jira that way. Thanks a lot.

6 answers

7 votes
Jack Brickey Community Leader Nov 16, 2020

Not really, no. Sprints should consist of story/task level issues. Subtasks are just a way to add some clarity or break the story into smaller bits of work. Regardless of whether you use subtasks or not the full story or task should be completed within the sprint. Now for subtasks and their usage in sprints, they inherit the sprint from their parent. 

Atlassian enforcing this seems to go against the simple agile manifesto.  For example 2 of the 4 big bullets

* Individuals and interactions over processes and tools

* Responding to change over following a plan

I have read multiple posts where users are requesting agility with subtasks.  I would prefer if Jira was infinitely nestable , any parent child relationship we want, pointed, in any story.

Like # people like this

No, they're not going against the manifesto. 

They're supporting Scrum.   Components or parts of sprint items are not sprint items in their own right, that's nonsense in Scrum.  

It's not a case of "enforcing" anything, it's a case of "this is a Scrum tool, and this is how Scrum works"

I think there is a failure here in Jira's reporting functionality - I would argue that a sub-task should have a searchable (but not editable) sprint field.  It should inherite directly from its parent, so that you can see that it is part of a sprint (because its parent story is) when asking "show me everything in a sprint"

What you really want to talk about is if Scrum goes against the manifesto, not Jira.  I'd argue that it probably doesn't, but I'm no authority on it, just an ordinary scrum master.

Like # people like this

The problem is not in the field of "sub-task is a part of story" here but in that we need more nesting support. Nobody needs a sub-task to be alone in the dark and cold. We want a usable Themes-Initiatives-Epics-Story/Task structure, so one could decompose his project into deliverable bits and bins and put them into boards :) 

Like # people like this

>Nobody needs a sub-task to be alone in the dark and cold.

Yep, they're not, they're part of their parent!

>We want a usable Themes-Initiatives-Epics-Story/Task structure, 

Epic-Story-Task is built into Jira Software, so we already have that.  Atlassian recommend the use of Advanced Roadmaps to go up into Themes and Initiatives, and Align if you want to scale higher.

Like # people like this

Hi, @Sage Arbor & @rokunin (welcome to the community).

I don't disagree with what @Nic Brough -Adaptavist-  said above in the least. This is exactly what Atlassian recommends.

However, IF you're looking for infinite nestability and flexibility I think you may find Advanced Roadmaps and Align to be more prescriptive than you'd like. They align (no pun intended) with Jira.

All is not lost...  There are other, and perhaps more affordable, Jira apps that add these capabilities to Jira.

BigPicture and Structure (full disclosure, I work for the company that makes Structure) are the ones I see "in the field" most often, but there are other options, too.

This search (or a similar search of your own) will help you find things you may want to consider:

Product: your flavor of Jira
Hosting Type: your hosting type
Best(?) Search Term in this case: Hierarchy (the same as nesting, but that's not a common term around here the way "hierarchy" is -- in fact, if you use "nesting" there are zero results returned)

Here's an example:

https://marketplace.atlassian.com/addons/app/jira/top-selling?hosting=cloud&query=Hierarchy 

I used "top-selling" mostly because that's what most people are looking for — tried and true.  But, admittedly, Structure is first on the list when you do that. ;) 

You can sort the list any which way you'd like of course.

Hope this helps, 

-dave [ALM Works]

Like # people like this

Sorry Dave, yes, I should have mentioned the alternatives!  I slipped up this time!

Like # people like this

Thanks, @Dave Rosenlund _Tempo_ 

We use the corporate (and feature-wise much outdated) server jira solution with close to zero chance to update it to the Cloud, so we stuck there. Some updates come at some point, but almost all the fun stuff stays in the cloud or works super clumsy. We have the BigPicture plugin but the infrastructure is so huge (5k+ employees) that waiting time for say gantt or board update (Ctrl+R) could take literal minutes. So we're lurking there with some hopes of longer hierarchy that could come in a form of core functionality server update but I guess as or today we're hopeless :)

Like # people like this

@rokunin  If I were you, I'd talk to the BigPicture folks about optimizing performance. I bet they can help you get that 5-minutes way, way down.  ;)

You probably already know this, but you can reach them via support@softwareplant.com. 

-dave

Like Kan Wong likes this
Anna-BigPicture Marketplace Partner May 04, 2022

Hi @rokunin

Performance issues may be dictated by many different factors and have a totally different background, depending on, among other things, the use-cases of our plugins and the environment in which the plugins are used.
 
 
We always offer our assistance in solving issues. Therefore, please, raise a ticket via our Service Desk, providing us with more details. This will allow our product specialists and developers to investigate your instance individually.
Like Kan Wong likes this

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. 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 tasks, or you turn the road map into a vomit of disconnected deliverables, but gaining the ability to treat each Issue like a subtask of the deliverable.

 

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

>This self-imposed limitation in Jira is ridiculous.

I am sorry to have to sound like I have not read the rest of your post, but I have. There's a lot of good thought in it, but despite the focus on "self imposed limitation being ridculous", it actually works out as "not doing it the way Jira pushes you to" does not work.

I'm going to pick out some things:

>The question is, can it help people do what needs to be done given their particular situation.
Yes. Probably. Jira is an issue tracker at it's heart, it probably can track the issues, whatever the methodology.

>Without even discussing the justification for including subtasks directly in sprints, it shouldn't be fundamentally restricted.
It's not "restricted", it is understanding that a sub-task is part of an issue

>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.
Again, it is understanding that a sub-task is part of an issue

>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."
Yes, and that's the howling anti-pattern we see ... just.. so ... too... frequntly...

You really need to stop doing that. You need your people to work together. Stop making it hard for them.



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

That is the defintion of a user story - do that.

>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).
Yep, that works too - a sub-task is part of a story.

> 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.
As you already said, a sub-task is part of a story

I have not ignored the rest of your post, I think a lot of it needs to be re-read in light of this answer

I hear you.

While we all wish the scaling of parent child items would not cost extra, this is the reality and we can't change that.

We also can't change the fact the Jira is built with a certain architecture where a story is defined as a work order and subtasks are internal steps to complete that work order. The epic is a container, the story is the work order and subtasks optional steps to complete the story.

What you are experiencing is the gap that exist as Jira is an operational tool designed for Agile teams. While there are some strategic support in Advanced Roadmaps, you still don't have any real support for strategy in any of the Atlassian tools, except maybe in Align that is still a black box for most of us.

For your mental model to work, you actually need at least one additional level, or you need to model things "sideways" by having two Jira projects where one act as the strategic level and one as the operational level. I know some teams add custom fields or abuse the components field as options as well.

I know that this is not what you want to hear, but that is the reality and it will not change anytime soon, unfortunately.

It's not a "gap", it's supporting Scrum.

Scrum is for self-organising teams, it has nothing to say about groups of teams other than "make sure you work with others well"

This is not going to change, unless some new model of working (that fits with Agile and is wildly different to) comes along and is adopted widely.  If you do want to use Jira to work with groups of teams, then, yes, you should look to epps that enable Jira to do that - Advanced Roadmaps and Jira Align are the two that Atlassian will plug, but there are a few others in the marketplace (Big Picture, Structure, Easy Agile and so-on)

Like Dave Rosenlund _Tempo_ likes this

@Nic Brough -Adaptavist-as far as I know, Scrum does not define what types of work you must use or in what structure they should be? It is up to each team, is it not?

@Kan Wong  As others have said, Jira was designed to (primarily) support individual teams. That said, there are lots of organizations that use Jira as a foundation for managing complex projects in a variety of ways.

Once you get past the fact that Jira out-of-the-box is designed to support your Scrum and/or Kanban teams teams — and that you'll have to extend it for doing things another way, you'll be fine. I personally know of many organizations that bend Jira to their will (and many others that like the way Jira imposes a uniform rigor to Agile processes).  I even know organizations that use a mix of the two — Jira as-is and Jira extended, to support a specific team's way of doing things.

@Kelly Arrey and his organization is a great example of this, as described in this article.

Like # people like this

Yes, that's at the root of my explanations here.

Scrum defines the "type" of work as "an item you can track, and hence work on during a sprint".  Most of us are familiar with those items being called Stories, but a better, wider, definition is something more like "sprint-able items". (A clumsy term, but I've yet to find a better short way to say it)

Jira implements the Story items as issues and lets you have many names for different types.  Sub-tasks are part of a story and hence not sprint-able items.

If you want to use sub-tasks to break up stories, that is entirely up to the team (Scrum is for "self organising" teams), but you have to understand that they are not sprint-able items themselves, they are a piece of their sprint item.

Like # people like this
3 votes

You put a sub-task in a sprint by placing its parent issue in the sprint.  Sub-tasks are a part of an issue, not separate stories in their own right, and hence can only be part of a sprint by virtue of their parent being in it.

I see absolutely no reason why we couldn't add a subtask without its parent to sprint. Keeping to rigid scrum rules is absurd. There are projects and industries where it is necessary. But there are also those where it not only makes work and order more difficult, but also makes you not want to work with Jira.

An ideal solution would be an option that allows admins to enable and disable the option of adding a subtask without a parent to a sprint. It would be an ideal compromise between those who want to stick strictly to the principles of Scrum and those who want to run their projects in a different, more practical way.

I encourage you to vote for this feature:

https://jira.atlassian.com/browse/JSWCLOUD-5797

I am sure that when we collect only 1000 votes, Jira will introduce such a solution.

Yeah, they should have closed that one with "not an improvement, won't do it" years ago.

Sub-tasks are not sprint items, they're a part of a larger issue.  See the previous explanations above.

Atlassian would need to do a paradigm shift from a prescriptive this-is-how-its-done Agile to a flexible, adapt-as-you-like Agile in order for something like this to go through.

Like Marek Pałyga likes this

I read all your explanations. I don't agree with your theories. In my opinion, you are fanatically obsessed with the scrum methodology. I don't care what the name of the methodology I use is called. I am interested in the fact that the solutions I use work for my team and allow me to dynamically develop my business. Jira should not be a tool that blindly follows the rules of work in a specific methodology. Jira should be able to adapt to the user's needs. Jira should be a flexible tool. Otherwise, it will become a monument to its former glory. Just like Nokia today. I want to use hybrid solutions and I don't care what I call it. However, Jira is the closest to my needs out of all the available tools.

You know nothing about my projects and needs in my business. You don't know what the specifics of my industry look like, so don't tell me what my job should look like. I don't need 100% scrum, but something close to this solution. And yes, I can work 100% scrum. But in this case, I don't need it.

I don't want to start a discussion with you because I've read all your statements on this subject and I think you're a crazy man.

If Jeff Sutherland had worked according to the methodologies adopted at that time over 30 years ago, your scrum would never have even been created. Today you would still be creating Gantt charts. Don't limit progress.

>I read all your explanations.

Thank you, it is good to be told that someone is listening to what you say.  When people write things and publish it, you don't get the feedback that you do from an in-person, or live-video conversation.

>I don't agree with your theories.

Most of what I have said is about how it works.  It's not something you can "disagree" with, it's not an opinion, it's how it is.

>In my opinion, you are fanatically obsessed with the scrum methodology. 

I take exception to "fanatically obsessed with Scrum".  I have obsessive tendencies (don't we all?), but "sticking to Scrum" is not one of them.  It would be more accurate to say that I am very pedantic about describing and defining things.  I'm very focused on accuracy and clarity, and that's about everything I work and live with, not just development methodologies.  

I don't really care about how you choose to work, beyond hoping that it works well for you!  If you and your team are happy with it, great. 

If you're working within a framework that has a name, fine, if you're not, also fine.  Just don't pretend you're doing <x> when you're not.


>Jira should not be a tool that blindly follows the rules of work in a specific methodology. Jira should be able to adapt to the user's needs. Jira should be a flexible tool.

It is a flexible tool.  The thing you seem to be missing here is that the parts of it that support Scrum are not suitable for doing things that are not Scrum.

>Just like Nokia today.

Heh, now that's an interesting story, but not for now.

>I want to use hybrid solutions and I don't care what I call it.

Yep, same here, do what works.  Just don't pretend to be doing Scrum when you're not, or try to botch Scrum tools to not do Scrum.

>However, Jira is the closest to my needs out of all the available tools.

Excellent.  It is a good tool, for a wide range of things.

>You know nothing about my projects and needs in my business. 

Nope, you've not explained it beyond "we don't do Scrum", I'm happy to talk about non-scrum ways of working with Jira, but you need to grasp that Jira Software's Scrum boards are for doing Scrum, so they might not be the right tool for your non-Scrum teams.

>I don't want to start a discussion with you because I've read all your statements on this subject and I think you're a crazy man.

Wow.  You've read all my statements on this here?  I'd say "scrum vs not-scrum" is less than 1% of my Community postings, but working with 1% means several thousand posts over the last 19 years...

"Crazy man" - I think you might mean that in a bad way, but I do not take it as such.  I think it means "someone who has such a different understanding of something to me, I really cannot grasp what they are thinking".  It's probably a two-way thing.

>If Jeff Sutherland had worked according to the methodologies adopted at that time over 30 years ago, your scrum would never have even been created.

Jeff's whole point of Scrum was not doing what you're trying to do. If you want to resort to name-dropping, I've worked in (Agile) teams that included Ken Schwaber and Martin Fowler.  And Jon Kern, whom I've separated out because I've not worked with him in a team directly, but I can (and have) yelled "hey, fellow Adaptavist, can you help?"

Like Kan Wong likes this
2 votes

Is there a reason you can not break out the sub-task to become a task instead? Also, what is the reason to not bring in the task itself? It can live in two sprints if you will only partially do the activities it contains?

Like many others I had the same question

So I googled and I found all these answers here ...

https://community.atlassian.com/t5/Jira-questions/How-handle-story-with-subtasks-in-different-sprints/qaq-p/1519368

https://community.atlassian.com/t5/Jira-questions/Can-I-move-sub-tasks-to-different-sprints/qaq-p/957897

https://community.atlassian.com/t5/Jira-questions/Separating-sub-tasks-sprints-from-their-parent-task/qaq-p/1550519

https://community.atlassian.com/t5/Jira-questions/Can-we-move-subtasks-to-different-sprints/qaq-p/1039069

https://community.atlassian.com/t5/Jira-questions/Stories-and-Sub-tasks-in-multiple-sprints/qaq-p/1032445

https://community.atlassian.com/t5/Jira-questions/How-to-move-ONLY-the-remaining-sub-tasks-to-new-Sprint/qaq-p/1259047

(here) https://community.atlassian.com/t5/Jira-Software-questions/How-to-assign-subtask-to-specific-sprint/qaq-p/1534931

Short Answer is that SubTasks have to stay with their Story parent in the same Sprint.

In almost every discussion @Nic Brough -Adaptavist- is involved and has to give the same answers over and over again. I guess he is already very annoyed buy that reoccurring question.

I understand that Scrum is defined like that, and doing something else is then simply not Scrum, but something else that doesn't have a name yet. But if you try to sell it as Scrum then it's simply wrong-Scrum. All clear and correct.

But if so many ask the same question, maybe Scrum is just not the best for all companies and something new has to be defined. But who provides a flexible tool on the market that can be adapted to their use cases? Atlassian will not, that I can tell from all the answers in the links above. And that's okay, if Atlassian decides "we only provide a real Scrum tool" then that is their decision and it has to be respected, right?

So we also got Stories that can not be broken down into further logical parts, so we can only break them into fake pieces like "Task XYZ - part 1 of 2" and "Task XYZ - part 2 of 2" and then we can put them in different Sprints. Sounds like a job for Sub-Tasks, but as we learned it's not what Scrum defines. So instead we end up with 2 Stories, where one could think it's 2 separate Stories, but in reality it's the same task, only broken into pieces because the tool doesn't support putting Sub-Tasks in different Sprints.

Great, so none of the solutions above is really satisfying and maybe Scrum is not for everyone, or Scrum is not yet mature enough or many just try to mix their old habits with Scrum and end up with something that is not really Scrum. I don't know and I also don't care.

That were my 2 Cents cause it was fun to read all these Forum posts discussing the same all over again. Maybe it helps someone to come to a conclusion.

@Marco Trosi 

Great research! I appreciate! And I share your opinion.
Recently, I came to the conclusion that the solution could be a completely new plugin that would work with a kanban board, but would imitate the backlog in scrum projects. In kanban projects, you can see tasks and add them without a parent.

I am at the stage of talks with developers and valuation of such a solution. Maybe creating such a plugin will be possible. I will accept any support from the Atlassian community to implement this solution. Maybe we should form a team to create something like this?

Like Kan Wong likes this

Hello @Marek Pałyga 
thanks for your feedback.
At the moment it looks like our company is switching to Polarion.

Sorry :-(

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
PERMISSIONS LEVEL
Site Admin
TAGS

Atlassian Community Events