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.