Can't put in subtask in active sprint

[Jovan Stanic]

Can someone explain me how to put subtask in active sprint, when the main task is done and it's located in past sprint? Is this possible at all?

[Nic Brough -Adaptavist-]

Welcome to the community!

Sub-tasks are not items that go into a sprint.  Of course, they do really, but only because they are part of their parent issue, which can be in a sprint.

The only way to get your sub-task into a sprint is to re-open the parent and bring that into the sprint.  Or move the sub-task so that it is part of a different issue that is going into the sprint.

I'd also take a look at your process, to prevent you landing in this logically nonsensical place.  You have broken data when you say "issue done, but sub-task not" - the sub-task is part of the parent, so how can the parent be done when part of it is not?

[Andy Mason]

Hi, on this topic.

I have a task that has 4 sub tasks but we only want to include 2 of them in the first sprint ... is there a way of doing this or is it all or nothing?

[Nic Brough -Adaptavist-]

That would be nonsense, as a sub-task is part of its parent.

Technically, sub-tasks don't even go into sprints, we just treat them as such because they are a part of their parent.

But, yes, you can split them - by moving them to different parent issues so they can be part of things that do go into different sprints.

[Andy Mason]

Nonsense? Or just something that works for me and my team?

[Nic Brough -Adaptavist-]

It's nonsense in Scrum.  You don't take bits of a story between sprints.

It might well work for your team, but that does mean you're not doing Scrum and will need to recognise that a Scrum tool such as Jira is for Scrum and so is unlikely to be that helpful for non-Scrum process.

[Dan R]

Lengthy post to bring this back to life. Sorry. 

I keep seeing a response to the request to split an issue across sprints as it's just not done- that it's "nonsense in SCRUM." 

I'm learning the process of using JIRA, and am clear now that Issues are 'atomic' with respect to Sprints. You can't split an issue across Sprints. I get it. But the reason people are asking this is because, in their mind, a User Story may be composed of subtasks that don't get finished all at once. I know that by definition in JIRA- because of the hierarchy built into the the tool- That the person managing the scrum can not break the issue across sprints. But the reason I see being given is a tautology. You can't do different subtasks across sprints because because you don't do that in JIRA. Well- yes. Clearly we won't. Because we can't. 

I could use advice- it would be helpful approach if someone could explain how we can achieve what we are after by altering the way we manage our issues and epics.

Let's say we have a user story: "Customer needs to be able to manage their profile on the application." It's composed of items that are in NOT in one sprint- (1) Change your email address. (2) update your profile photo. (3) Add your birthday. Yes, this is a high level story, but people are writing the story at the 'issue' level and making the different things that compose the story into subtasks.

Is the correct approach to make that an "Epic" and then have the different components of the story- which is now an epic- be Issues that are in multiple Sprints?   

So the "Epic" would be "Profile Management"-- and the tasks flow from that, to be built across sprints? 

I think the answer is to move what these folks (myself included) see as "User Stories" up to the Epic level, and have the details down in separate issues. 

Advice here? 

[Nic Brough -Adaptavist-]

I see what you're getting at, but it's not quite a tautology.  Let me rewrite

You can't do different subtasks across sprints because you don't do that in Jira. 

to the actual reason:

You can't do different subtasks across sprints in Jira because Scrum does not work that way (sub tasks are not sprint items, they are part of sprint items), and Jira is a Scrum tool.

You then propose:

Is the correct approach to make that an "Epic" and then have the different components of the story- which is now an epic- be Issues that are in multiple Sprints?   

Yes, spot on! that is exactly what Epics are for - gathering together related stories (items at a size that is acheivable in a sprint) and carrying them forward over many sprints

[Dan R]

Ok- the latest I heard, from one of the JIRA acolytes here at work, was that we should keep our Stories (Issues? Story==Issue, but that's a topic for another day. :)) as is, and add subtasks. And if we don't finish a Story in a sprint- if there are still open Subtasks, we should just-

- Mark as completed/finished those subtasks that are done.

- Close/end the Sprint

- And in the next sprint (re)include the still-unfinished Issue and the still open Subtasks. 

What do you think of that as an approach to keeping work open across sprints for issues that are composed of work that would take longer than one sprint?

Alternately, we can push to keep with a convention that 'Issues/Stories are finished in a sprint" and try to keep them sized so they fit within an entire sprint. 

(If I've totally taken a left-turn on the original post, I can repost as new question to the community.)

[Nic Brough -Adaptavist-]

Yes, that's exactly what Scrum says on the most part.

The bit that is not Scrum is "we expect stories to move across sprints".  The whole point of a sprint is that you commit to completing a set of stories in it.  You can't do that if a story is too big for a sprint.  If you find you've got a large story, you should refine it into several smaller stories that do fit inside a sprint, and then link them together somehow (possibly with Epics)

Stories are the things that you consider as either "things that need doing" or "things we have done".  (Issue is a generic term for Jira items that are at the level of Stories - you could have a mix of Stories, Bugs, Issues, Pengiosn - whatever you want to call an issue in your project)

Scrum doesn't have a lot to say about sub-tasks.  It's up to the team if they choose to use them to break up their stories into component parts, but in Jira, that is exactly what a sub-task is - part of a story, not something separate to it.

A sprint only looks at the story level issues.  It doesn't care about sub-tasks becauuse they are part of the stories.  If you have a story in a sprint, then all it's sub-tasks have to be as well - they're a part of it.  A story can only be done when all its pieces are done (if it has any).  So if a story is not done at the end of a sprint, it moves to the next one (or you stick it back in the backlog).

The critical point there is that a story is done or not.  It is not part done, it's a simple boolean done or not.  And it should be done inside a sprint.

[Chris Lee]

I think there is a perfectly valid use case for moving a subtask into a sprint without the parent story.  Adding a story to a sprint is a commitment by the team to finish that story during the sprint.  It has a direct impact on metrics against which teams are evaluated, such as velocity and completion rate.

However, occasionally a team member has extra capacity, especially towards the end of the sprint.  It is perfectly reasonable to get a head start on the next sprint's stories without committing to finishing the story in the current sprint.  A great way to accomplish that would be to pull an individual subtask from the next sprint into the current sprint.

Now sure, there's nothing stopping you from writing a board query that shows you everything being worked on, but not allowing the subtask to move means you can't take advantage of a wealth of built-in queries and reports.

The only real alternative is to break out a separate high-level task and reassign the subtask to it.  However, that breaks the subtask (hours) to story (complexity) correlation in the metrics, which is a useful thing to track.

[Chris Lee]

The converse, which is what the OP asked, is a bit dangerous because it falsely claims stories are complete even when there are outstanding items.  That manipulates metrics around story point completion and "hides" work, which is an unhealthy practice for an organization.  It is better to either carry over the story and finish it the next sprint, or to create new bugs/tasks/stories that cover additional deferred work, so that the story can be completed cleanly.

[Nic Brough -Adaptavist-]

I'm going to have to be quite brutal here (or write a 12 page essay).

That's nonsense.  You do not seem to understand what scrum is for, let alone any concept of  Agile (this is more common than you might think.  Around 80% of the "scrum" teams I run into have similar misconceptions or poor understanding of it similarly to you, and they really aren't Agile, let alone doing scrum "properly")

Your "occasionally a team member has extra capacity, especially towards the end of the sprint." says a lot.  It is perfectly reasonable to get a head start on the next sprint's stories without committing to finishing the story in the current sprint." . After you did what you said you would.  Free time, great, after you deliver your promises.

It is not "perfectly reasonable" to go off and do something else and fail miserably to do what you said you would do.  Your team *must* deliver what they said they would before people start picking up other bits.

It's a bloody horrible thing to do.  You should be delivering what you said you would.

If you genuinely think this is an acceptable way to work, then you really need to stop trying to pretending to be Agile, just admit to your users that you're just going to work on what you feel like, not what you said you would or what they want.

You are, of course, right about picking up extra work.  If your team has completed everything they said they would, then heck yes, get them to pick up other stuff.  Doesn't matter if it's at the top or bottom of the backlog - it's all a bonus and improves the delivery.

[Chris Lee]

That is naive.  There are sometimes tasks which cannot be parallelized or are blocked by external factors.  But, let's use your strawman as an example.  On the second to last day of the sprint, all stories have been completed, and there are just under two days left to complete additional work.  The top entry in the backlog will require at least three days of work.

At that point, the best course of action is to start working on subtasks for the upcoming story.  It would be nice if, during standup on the last day of the sprint, the subtasks in progress would show in the current sprint, without having the story itself be moved.

I understand your point about not taking on extra work until commitments are satisfied.  If you read my answers above, I specifically say that, and include reasons why instead of just saying it is "bloody horrible".

[Nic Brough -Adaptavist-]

Um, no, it's not "naive", it's the way it works.

Yes, tasks can get blocked - your scrum team takes account of blocked tasks when doing sprint planning.  Blocks are one of the reasons you do sprint planning.  

It doesn't actually matter to sub-tasks whether they're blocked individually, because they are not sprint items.  Their story is blocked because some of it can't be progressed, and for these stories, your team simply doesn't commit to doing them because they already know they can't do it.

I'm not sure I can explain more how "failing to deliver what we said we would" is "bloody horrible".  I'd have thought it's pretty clear - it shows a failed team that isn't delivering and hence you can't plan for.

[Diego Correia Aragão]

It is naive to think that the "Scrum script" is followed 100% in the daily routine of all software companies that allegedly use it. Scrum is a model, not a religion. There is not a single model that is 100% followed by all parts involved in any area of human processes. In fact, the Scrum guide does not say anything about tasks, sub-tasks or even user stories. Everything that comes from that is Jira's own interpretation of these processes and definitions, it is NOT Scrum itself.

The Scrum Guide says the following about the Sprint: "No changes are made that would endanger the Sprint Goal;". So, it is not a problem at all to anticipate work from an upcoming Sprint if it won't endanger the current Sprint's goal. I think this is completely feasible and it does not "harm" any of the Scrum values. The only reason Jira does not allow a sub-task to enter a Sprint, excluding technical limitations of course, is that it does not want it.

[Nic Brough -Adaptavist-]

Yes, I'm well aware that people vary the model.

But when they do, they can take it outside the Scrum model, and that's exactly what you're doing when you try to treat fragments of sprint items as sprint items in their own right.

In real life, there's nothing wrong with doing that - you're the owners of the process and you should work in a way that works for you.

But you can't expect a Scrum tool to support your non-Scrum process.  It's not Jira "not wanting to allow it", it's that you are not doing Scrum if you do it, and Jira is a Scrum tool.

[Jaron Foux]

"But you can't expect a Scrum tool to support your non-Scrum process."

I actually can. Jira lets me do it all the time with all the crazy custom set ups we use that don't fall into regular old Scrum processes. I explicitly set up my fields for Tasks and Sub Tasks to be identical, and this is the one place where for some reason, Jira simply decides that I can't edit the field for one issue type over the other. 

It's stupid design. There is no logical reason why I can't put sub tasks into a sprint by simply enabling the field for the issue type. You can have your rigid, unchanging by-the-books version of sub tasks. 

But if I tell the tool to use the same fields for both issue types, and it ignores what I tell it to do, it's legitimately bad UX design. 

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

I'm curious, do you mean you have you set up your "sub tasks" at the same level as the stories?  (So they are not sub-tasks)?

That works fine, it fits within the Scum model.

[Jaron Foux]

I'm not sure what you're saying. I didn't mention stories at all. I have tasks and sub tasks using identical configurations across the board. Jira just decides that the sprint field shouldn't appear for sub tasks despite me explicitly saying that it should. There's no reason for the UX to do that. 

[Nic Brough -Adaptavist-]

Sorry, I was not clear there.

Jira has "levels" of issues, for want of a better phrase.  The main two in core Jira are "Issues" which can then have "sub-tasks".  Both levels can have many types.

Scrum usually talks about "Stories".  In Jira, these are usually configured as an "Issue" level issue type.  You usually see projects having issue types named as Story, Bug, Task, and then sub-task types named like "technical task" or "defect".

The word that is very variable across the Jira world is "task" - some places have tasks on the base-issue level, others create them as sub-tasks (Bug and Defect are also seen across levels, but a lot less).  Stories are the opposite - I've never seen anyone define a story at a sub-task level, they are always base-issue level.

Anyway, moving away from Jira-speak, the point is that sub-tasks are a part of their parent in Jira.  It's nonsense to try to speak of them as sprint items in Scrum.  It's a bit like saying your left leg is going to try to do a park run two weeks later than the rest of your body does it tomorrow.

But it would be useful for Jira to display that.  I regularly use Scriptrunner to create a scripted field that displays the sprints the sub-tasks parent issue is in.

[Eric Schwieterman]

Our organization is battling the same thing.  We are using Epics for higher level outcomes and groupings.  We then use stories to help with delivering of those features.  Those features at times have multiple engineering tasks to complete.  Due to the complexity of our systems completing in a single sprint can be hard or cumbersome.  Because sub-tasks only allow for an all or none approach in the sprint it now relies on our Product Team to create stories to comply with JIRA's handling of sub-tasks.  

JIRA has the perfect thing in sub-tasks that would solve our issue but because of the hard and fast rule of sub-tasks it now complicates the entire process.  

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

You say "Due to the complexity of our systems completing in a single sprint can be hard or cumbersome."

That points to a process problem within the team, but one that is being imposed from outside.  "Completing in a single sprint" is the crux of the problem, it tells us that your team, or your business, or both, are not decomposing stories down enough.  A story should always be complete-able within a sprint.

The point of a sprint is to deliver an incremental improvement or change that can be measured.  If things move into a new sprint, then the team has failed to deliver that improvement, and needs to do some introspection on why.

If you have issues that can not be estimated to be complete within a single sprint, you need to look at why (a big part of Agile is looking at why your team is failing, roll-over is the biggest sign of failure).  There can be many reasons, and hence many ways to adjust your processes

• Dave was ill.  Fine, you can't fix that, it explains the roll-over, and we all hope Dave gets well soon.
• Bob has on holiday.  Again, it explains the roll-over, but holidays can be anticipated, so a quick "fix" for that is to have "Bob's holiday" as a story, with an estimate that is 1/7 th of the current velocity (assuming a team of 7).  This also makes the statistics look consistent!  My instinct is that it is a sort of cheat, because Bob's "effort" is actually "lounging around on a beach trying to reduce my stress levels" and Bob manages to rack up 1/7th of the estimate by doing that, but I've found it works well for the numbers.
• We are not breaking up our stories enough, they're too big to bring into a sprint.
• Your business does not understand Agile, and is over-complexifying, over-specifying things, or even trying to micro-manage the team.  Hard one to deal with, but your Scrum master and Product owner's job is to push back on the business and say "look, just tell us what you want, and we will define and/or refine the stories in ways that let us deliver them.  You are not telling us how to work")
• And the outlier - if your stories are well defined, and it does not make sense to break them down more, could it be as simple as your sprints are too short?  The usual recommendation is "start with a fortnight", but if you do have lots of non-decomposable stories, maybe three or four weeks would work better?  (Someone will probably say "one month sprints" if you suggest this, but that won't work until humans change our calendars to be 13 months of 28 days each, with 1 non-month day annually, and another extra one to handle leap years.  Stick with weeks)

[Eric Schwieterman]

I understand that's what the general rule for Agile is but from a Product and value add standpoint breaking up the individual story doesn't make any sense.  It's only breaks the work from the engineering side.  I would love for that work to be able to be completed in the same sprint it's just not possible without more overhead and planning which is a waste of money.  

Making the software flexible is only a value add.  Not all companies and situations are created equal so to follow a philosophy hinders teams.  

[Nic Brough -Adaptavist-]

It's not a "general rule for Agile", it's pretty much the point of Scrum.

Part of Scrum is re-evaluating when things go wrong, and it's a perfectly valid thing to do to say "well, Scrum isn't for us".  If you can't get your stories to fit within a sprint (either by qualifying them better, or lengthening the sprints), then Scrum is not for you.

[Troy Anderson]

Interesting conversation!  Glad I found it.

1. Now we have Parents instead of Epics.  Does that change anything?  Do the sprint boards support unlimited hierarchy?

2. If I am trying to manage existing sub-tasks into Sprints, then, is the solution to convert them all to Tasks (or whatever type of issue makes sense)?

[Nic Brough -Adaptavist-]

Hi Troy,

No, not really.  The move to "parents" is Atlassian trying to homogenise and simplify.

This is a welcome move for me - the way sub-tasks and Epics were related to mid-level issues over the last decade and a half was (and I'm trying to regulate my language here, please feel free to assume I originally typed this comment with many more bad words that I then deleted) was a massive pain in the arse.

I completely understand how they got there, and it is not even directly their fault but it was something that needed fixing years ago.  I am very glad that they have, but... it... has... taken way too long.

To answer the questions

1. No but yes.  If you only have plain Jira, the hierarchy is just issue and sub-task.  Jira Software gives you Epics above the issues.  So your sprint boards at least have three layers. 

If you are on Cloud premium, you can add as many layers as you want above the base-issues

2. Yes, I think you have the right answer here.  A sub-task is supposed to be a fragment of its parent issue, and hence follow its parent into a sprint.  If you have a sub-task that is not really part of another issue, then turn it into a separate taske.

[Universal Automations]

I am looking for a way to add Subtask to a sprint too. I got some suggestion that it was possible but then landed me here. Which tells me it is not possible. 

My problem is I need to maintain only one ticket for the parent task, and not start doing -part 1, part 2, part 3 just so that I can fit them in the sprint, the scope of this parent ticket is bigger than our 2 week sprints, and want to be able to include subtask tor a sprint. Also seems like many people would like to do it. 

Nic Brough -Adaptavist- Looks like many people are interested to have this feature, why not reach out to your development team and ask for their opinion to enable adding subtask. If Atlassian would like to make customers I think they should make the tool flexible and leave it to the customers team scrum or not. Think of every one who has posted here as your customers not give them more reasons to choose a different tool. People are here because they want to keep using Jira.  

[Eric Schwieterman]

I agree completely @Universal Automations

We are now having to devise different, less effective ways that sub-tasks could essentially solve the problem to.  I understand it's not by the book but what we are doing works for our teams so going by the book isn't an option.