You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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.
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.
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 :)
>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.
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:
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]
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 :)
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.
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)
@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.
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.
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:
I am sure that when we collect only 1000 votes, Jira will introduce such a solution.
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 many others I had the same question
So I googled and I found all these answers here ...
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.
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?