Alternatives to putting subtasks in different sprints?

[Arlene.Amaya]

I would like to put subtasks in different sprints, but from what I've read, there's no way to do that. Wondering what alternatives there may be? Something I'm considering is inserting a fourth level to hierarchy (Epic, Task/Bug/Story, Subtasks), perhaps between Epic and Task/Bug/Story. Any considerations I should keep in mind or alternatives to that approach?

[Trudy Claspill]

Hello @Arlene.Amaya 

Jira does not support adding an issue hierarchy level between Epic and the "standard" issues level.

Subtasks can't be added to sprints independently of their parent because they are not considered separate from their parents. The parent issue is the level at which sprint planning and velocity is measured. Issues at that level should be sized/scoped to be able to be completed within a sprint.

If the items that you currently have defined as subtasks need to be handled independently in Sprints then they will need to be converted to an issue type at the "standard" issues level (Story/Task/Bug). Or maybe you need to decompose the parent issues into more independent and smaller scoped issues and divide the original subtasks among them.

Tell us more about the problem you are trying to solve. Why do you think you need another level in the issue hierarchy? Maybe there is another way to address the problem.

[Chase Flinn]

The flaw in that logic is assuming the elements that make up a PBI will fit perfectly into a sprint. A story may start towards the end of the sprint and the QA work might want to be accounted for in another sprint.  The story is the outcome we want to achieve and we do not want to horizontally separate the QA portion just to account for it being in the next sprint. The story is done when all the work is done.

You should enable the ability to move subtask to separate sprints from the parent.

[Trudy Claspill]

@Chase Flinn 

If the QA work (subtask) is required to be complete in order for the parent issue to be complete, then the parent issue also needs to carry over to the next sprint. I don't understand why you would need to move the subtask to another sprint without also moving the parent issue.

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community @Chase Flinn 

I think you're missing the point of sprints here.  They do not assume stories will always fit within a sprint, that is simply what you should be aiming for.  Items carrying over into the next sprint means the team has failed to deliver what it said it would, and so needs to examine why it failed.

Sub-tasks are not sprint items, they are a fragment or a part of a story.  If you have decided to create QA as a separate part of a story, that's fine, but it is nonsense to to put them into a sprint as anything other than part of a story you have not finished.  Completion of a story is binary - it's done, or it is not.  Not done includes having bits that are not complete (i.e sub-tasks)

[Chase Flinn]

@Trudy Claspill very simple. Not all situations are the same and different teams are in different places in regards to their journey. Some teams especially in the SAFe framework (which I am not a fan of but work with in the bounds of my company) plan out a couple sprints ahead based on capacity. Also not all places have full stack or T-shape engineering teams. Still pretty common to have FE, BE and QA engineers on a team so each of them have their own "capacity". We might have a good idea PBI A,B,C will fit into the sprint but D and F we know we can get started but will overload QA so we want to move the subtask to the next sprint and pull it in if we have more capacity then we expect later. This way things line up from a capacity perspective. 

Again please don't preach like "that's not the right way though" because that's not the point right now. The point is the flaw in Jira pigeonholing everyone's functionality because of how they "feel" people should work rather than providing them options and allowing them to transition at their own rate.

@Nic Brough -Adaptavist- Most of what I said addresses your first item, though there is more nuance then your explanation leads on, especially the completion of a goal being more important then each individual item, that's not the conversation I'm looking for here. 

You're second statement I disagree with as well. Sub-task are inherently sprint items as they are typically the technical components that make up the PBI. If a PBI is in a sprint the sub-task are part of the sprint as well as a part of it. When that PBI gets done is beside the point. We don't disrupt the flow of work or deviate focus from the sprint goal just to try and make sure all work stops and starts within the sprint. Again my first explanation of a very possible scenario and it's not "nonsense" just because it's not how you work. You are correct though in saying stories are binary, but Jira's current functionality encourages horizontal slicing of stories in situations like this which is the habit I am trying to get this team away from first and foremost but Jira makes that difficult because it's stubbornly restrictive to its own ideals. 

[Trudy Claspill]

@Chase Flinn 

I am not preaching that assigning sub-tasks to sprints is "wrong". I am saying that the concept doesn't align with the basic concept (as I understand it) of the scrum agile framework. I don't have SAFe training, so I can't speak to how that applies here.

Reviewing the documentation from the Scrum Alliance, they mention that a PBI (Product Backlog Item) is selected for a sprint. I did not find any discussion of addressing sub-items that comprise the PBI and sprint-assignable work.

https://www.scrumalliance.org/about-scrum

Jira's design aligns with the idea that PBIs (a standard level issue) are the level of items that is a trackable element in a sprint. One can choose to break down the PBI (i.e. decompose a standard level issue into sub-tasks), but the work tracking from the sprint level applies to PBIs.

I personally have not been in the same situation as your describe, so I don't have any recommendations for how to make Jira do what you want, since what you want seems to be contrary to the design of the Jira product. I'm sure there are other folks that face the same situation.  Perhaps there ways to structure the work within the default Jira issue hierarchy, or a third party app that can be combined with Jira to achieve your desired functionality. Or, perhaps, Jira itself is not the right work tracking product for you, and you need to consider a product with more flexibility. I have worked with some other products that have a more flexible issue/item hierarchy. Each product has its own strengths and weaknesses. I don't think there is any one product that provides both all the flexibility and all the guardrails that are needed to support all variations agile frameworks.

[Chase Flinn]

@Trudy Claspill Scrum is intentionally incomplete so that others use the framework to find the process that works best for them. The practice of vertical slicing of stories is a good practice that incorporates all levels of a stack in a PBI in order to produce potentially useable increment. Vertical slicing is rooted in agile but not a scrum related thing. To keep it simple subtask are just slices of a technical stack that make up what's needed for a story to get feedback.

Jira's issue is it tries to create things from its own perspective of what scrum/agile is rather than allowing the freedom for people to use it how it works best for them in many cases. Personally I'm not a fan of Jira but that's besides the point since the decision to use it is not mine to make. Hoping if maybe enough people mention it they might do something about it but I've seen this question come up many times over the years in my search and I don't think they will do anything. Maybe I'll reach out to our company rep.

[Nic Brough -Adaptavist-]

@Chase Flinn  - it's the same answer.  Stop trying to use a Scrum tool to not do Scrum.

Vertical slicing does not work when you are trying to be Agile, because it defeats the point of being Agile (Let alone Scrum)

[Chase Flinn]

@Nic Brough -Adaptavist- the fact that you think Jira is a "scrum tool" leads me to believe we're not going to agree with each other. Jira is project management software that made a tweaks to try and market themselves as "agile software". 

Also your second statement is irrefutably false. A principle of agile is working software and the point of a story or PBI is to provide a potentially usable increment. You can't use something or get feedback on something that has been broken down so much that its only one component of a technical stack. That's the point of vertical slicing and it is very much so works with agile and scrum development. 

[Nic Brough -Adaptavist-]

@Chase Flinn  I think you're completely missing the point I am trying to make. 

Scrum does not have anything to say about sub-tasks, it only talks about sprint items.  Jira Software supports Scrum.  "Vertical slicing" as you seem to be using the term is not Agile, and it certainly isn't Scrum.

[Chase Flinn]

@Nic Brough -Adaptavist- No I'm stating reasons why the points you are making are wrong and you're just ignoring them. Never said scrum says anything about subtask, but I did mention it is an intentionally incomplete which means it allows people to find processes that work for them within the principles without being so prescriptive. 

The use of subtask to represent the layers of the stack in a PBI or story is not outside the realm of its principles nor is vertical slicing which you do not seem understand at the moment. If you don't want to believe me though here is a few quick finds you can reference or go have some conversations yourself. 

https://medium.com/@joe.muldoon001/succeed-with-scrum-with-vertically-sliced-stories-a02cb71fe867

https://www.youtube.com/watch?v=jQg27pFGmWA

[Nic Brough -Adaptavist-]

@Chase Flinn It does not look like you are giving us any argument that I am wrong, you just seem to be saying "that's not the way I want to work", which is not a problem for me, other than pretending to be Agile when it's not.

I think you should re-read and re-watch the links you've posted, they're saying what I am.

[Chase Flinn]

@Nic Brough -Adaptavist- I've been giving you arguments showing your wrong in both threads and you're responses have been the equivalent of "nuh uh".

You said verbatim "Vertical slicing does not work when you are trying to be Agile, because it defeats the point of being Agile (Let alone Scrum)" and I provided you 2 examples of others explaining what vertical slicing is and why it is better for agile teams. Subtask are a way to use a tool to allow developers to map out those horizontal components within the increment/vertical slice which is also explained in the items I sent. I really don't know how to lay it out anymore for you to understand if you're not getting it at this point...

[Nic Brough -Adaptavist-]

No, you provided no explanations, just pointed to stuff that mostly supports what I've been saying, which explains vertical slicing in a significantly different way to what you appear to think it is.

I am also very stuck here, I can not see a way to explain it in a way that you might understand (I know I struggle to communicate sometimes, I am not blaming you for my inability to explain).  I think we may have to "agree to disagree" in this case.

[Chase Flinn]

@Nic Brough -Adaptavist- seems like another "nu huh" retort. Claiming I provided no explanations is just flat out false and clearly evident in all my responses. I even laid out an example of comment you made, provided evidence and held your hand through the explanation piece by piece and your response was "your saying what I'm saying but just wrong". But yea agree to disagree.

[dhnhut]

Hi @Nic Brough -Adaptavist- 

I support the main points that subtasks should not be put in separate sprints and that a story should be done within a sprint.

However, I am really confused about your statement, "Vertical slicing does not work when you are trying to be Agile, because it defeats the point of being Agile (Let alone Scrum)". Could you please explain more about your opinion?

Thank you!