nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How handle story with subtasks in different sprints?

Steve Fogel_3cp22a

What's the strategy for handling a story that will likely span multiple sprints and have sub-tasks in different sprints? Looks like sub-tasks inherit the sprint field from the parent story.

Would also like to know best practice for punting the story to the next sprint if not all sub-tasks are complete. Thanks

Accepted answers

sudarshan_x34rab

Hello @Steve Fogel

The best agile practice or the must practice is better User Story Slicing in such a case.

If a User Story has too many subtasks which span over multiple sprints, then you will have to split the requirement which can be delivered within a sprint (DOD).

And yes, Sub-Tasks is inherited from the parent sprint ID.

Elias Hajjar

Sudarshan TS mentioned, one of the criteria for a story is it should be small that it can fit into 1 sprint. This is the official answer. The semi unofficial answer is, slice the story by dev and QA and define your acceptance criteria on acceptance of the acceptance criteria. with that being said, this should not be the normal process. the normal process is to slice the story into smaller stories. If you can create sub-tasks that make up the requirement of the story then you might be able to create new smaller stories and link them back to your original story.

Maybe if you explain the specifics with examples i might be able to help little more.

cheers

Deepanshu Natani

Hi @Steve Fogel

The best practice is to keep a story as small which can be completed within a sprint.

If the story cant be completed in a sprint, you will not be able to reap the actual benefits of Scrum.

Nic Brough -Adaptavist-

You can't do this at all. Sub-tasks are part of their parent, and hence not even considered to be part of a sprint. They go with their stories into a sprint, all together because they are a part of their parent.

The concept of having sub-tasks in different sprints is simply wrong. The parent goes into a sprint and, because the sub-tasks are part of it, they go with it.

If you are regularly finding you are partially completing a story and hence rolling it into the next sprint (with its component sub-tasks), then you either need to improve your estimates and sprint selection, so that you don't commit to too much work, or improve your story writing, breaking up your stories more, so that you can commit to the right amount of work by only taking in what you can do.

Nic Brough -Adaptavist-

>i know that's wrong but i was bringing it up as an inefficient way to handle dependency.

There is no more efficient way to handle dependency

>a dependency can have dependency and so forth. so where do you start?

With the first one that doesn't have any

>if you want the story to be independent then you have to have no dependency. Agree?

No, not in the slightest. Two stories are independent in the sense that they are separate item. A dependency is not a story, it's a link that says "we can't do this story because that one needs doing first". The two stories at each end of that link are independent. But one depends on the other being done.

>if you agree then that means you can implement any 2 stories in the same sprint, correct?

Yes, that's the point of a sprint, you commit to dealing with one or many stories at the top of your backlog inside a certain time.

So going back to where you seem to have a problem - if a story does not fit within a sprint, then you need to break it up into separate pieces that can be tackled in the sprint. If that creates a dependency, fine, you note it an move the dependency higher in the backlog so it gets done before the other one. That won't be in the same sprint, of course, because added together, you already know their sizes added together make them too big for a sprint.

All comments

sudarshan_x34rab

Hello @Steve Fogel

The best agile practice or the must practice is better User Story Slicing in such a case.

If a User Story has too many subtasks which span over multiple sprints, then you will have to split the requirement which can be delivered within a sprint (DOD).

And yes, Sub-Tasks is inherited from the parent sprint ID.

Elias Hajjar

Maybe if you explain the specifics with examples i might be able to help little more.

cheers

Deepanshu Natani

Hi @Steve Fogel

The best practice is to keep a story as small which can be completed within a sprint.

If the story cant be completed in a sprint, you will not be able to reap the actual benefits of Scrum.

Nic Brough -Adaptavist-

The concept of having sub-tasks in different sprints is simply wrong. The parent goes into a sprint and, because the sub-tasks are part of it, they go with it.

Elias Hajjar

what you say is the ideal world. its not only the size of the story that dictate taking more than 1 sprint. its also the other dependencies such as another story that need to be competed in order to test the first one and call it done

cheers.

sudarshan_x34rab

Looks like an interesting thread.!
@Elias Hajjar a happy story (which is well cut and follows "INVEST")

The Aim is to make every story a happy story.! (Independent, negotiable, Valuable, Estimable, Small, Testable).

Nic Brough -Adaptavist-

You say:

"its not only the size of the story that dictate taking more than 1 sprint. its also the other dependencies such as another story"

These are separate stories - if you have dependent tasks, then they should be in other stories and ranked higher than the original story. They should then be brought into a sprint and the original not brought into the sprint if it would take your commitment too high to fit in the sprint.

If your story is too large to be done in a sprint, you really need to be decomposing it into smaller stories.

Nic Brough -Adaptavist-

>i know that's wrong but i was bringing it up as an inefficient way to handle dependency.

There is no more efficient way to handle dependency

>a dependency can have dependency and so forth. so where do you start?

With the first one that doesn't have any

>if you want the story to be independent then you have to have no dependency. Agree?

>if you agree then that means you can implement any 2 stories in the same sprint, correct?

Yes, that's the point of a sprint, you commit to dealing with one or many stories at the top of your backlog inside a certain time.

Heidi Fox_loljww

I was taught by a Scrum coach that stories can be larger than sprints and that the right thing to do is to split them into subtasks which are then assigned to separate sprints. Otherwise, you don't end up with actual User Stories but partial User Stories and the actual user stories end up as Epics (and there's then no way in JIRA to manage an actual epic).

E.g. User wants to be able to search for a coffee shop along the route that they are currently driving.

That is a user story that will inherently take more than one sprint. You cannot make it smaller without it no longer being a user story. "User wants to be able to represent a route in such a way that searching along it is possible - part 1?"

Nic Brough -Adaptavist-

That's incorrect. If a story is too large for a sprint, you either split it into smaller stories, or promote it to an Epic and reduce it to managable stories.

Scrum says nothing about the use of sub-tasks.

Heidi Fox_loljww

So it really *is* valid to have a "user story* that says 'user wants to have a Postgres database table implemented to hold the user's settings."?

Rajesh Viswanathan

Thanks for the good discussion's

John Kagan

Here's an example we are dealing with - I would be interested to hear recommendations on connecting these "how" Subtasks with their "why" Stories:

We have a UI/UX team that processes new system changes first (user interviews, wireframing interfaces, functionality analysis, etc.) The output of these UI/UX Subtasks, in collaboration with the Dev team, is a set of new Dev Subtasks for implementation.

We are deliberately separating the UI/UX and Dev Subtasks into separate Sprints to manage blocking dependencies - i.e. we know that the Dev Subtasks aren't blocked because the UI/UX Subtasks were already completed in the previous Sprint.

Since the UI/UX and Dev Subtasks are both "how" details for the same "why" Story, it doesn't feel right to slice the Story to separate the Subtasks.

The Stories aren't large enough to warrant getting promoted to Epics (the Stories are already part of Epics)

We could use Tasks instead of Subtasks, but that doesn't feel like it is capturing the relationship to the Stories as accurately as Subtasks would

Nic Brough -Adaptavist-

>We are deliberately separating the UI/UX and Dev Subtasks into separate Sprints to manage blocking dependencies
Ok, that's "wrong". A story is something that should be possible to complete within a sprint, completed by the same team.

This sounds like you have two teams working on the story independently. As a sprint belongs to one team only, this will not work. Remember that stories rolling from one sprint to another is supposed to be an exception, and is something that should be talked about in your retrospective as a failure and inform ways to improve.

"Sub-tasks in separate sprints" is totally wrong, you never do that, and good Scrum software simply won't let you. Multiple sprints, yes, but not different ones. A sub-task is part of an issue, and it's the issue that goes into a sprint, with all of its components (and rolls over if things don't work out)

The best way you could handle this is to have two stories, as you have two teams. Pick which team is likely to work on it first, and then work out at what point a second story should spawn from it. Automate that and have it do it in the second teams backlog.

The most simple example - you have a UX team and a Dev team. Have a project for each team, with a scrum board for each. When a new story arrives, create it in the UX project, and have a workflow that maybe does something like new -> in initial design -> polishing -> done. When it moves from "initial design" to "polishing", create an issue in the dev project linked back to the design issue. The developers can then run with that, and know where it came from.

Elias Hajjar

I'm sorry that's exactly what i answered above then " Sudarshan COMMUNITY LEADER Oct 29, 2020" answered "the story should be independent" . So doesn't breaking this into 2 stories UX and DEV makes the Dev story dependent on UX story?

Emily Collins

Good morning! I have a similar issue but slightly different reason -

I am trying to use the 'Plan' view, so that there is transparency about when things are likely to be worked on/completed, without having to interrupt the team with meetings/emails.

The team has decided that stories should be customer value based, and as such we are finding certain stories can end up having quite a few sub-tasks, that are not necessarily achievable within a 2 week period (our sprints).

We have considered splitting the stories down even further, but it becomes quite laborious/low value to discuss and confusing to resolve later if we split certain stories purely to fit within a 2 week period to conform to JIRA limitations, and it creates complexity in the size of our stories and the customer value for each story which we would prefer to avoid.

The issue is that when we "plan" (via start date and end date) for roughly when we can address a specific subtask (ie. it might only be 1 day later) we get an error appear on our 'plan' view that says the subtask is falling outside the assigned sprint.

Would love to have the option to:
- Assign a story to multiple sprints (if needed)
- Remove or edit the prepopulated sprint field within the subtask (currently locked)
- Be able to "ignore" an error in the plan view for these circumstances so we don't keep checking the same thing and wasting time planning/discussing/focusing on things that are not our immediate priority.

Is there a way to do this? Or is this on a backlog somewhere?

Thank-you so much!

Also was very interested to read this thread, but I feel disappointed in the way that we are speaking to each other. I don't think Scrum or Agile are any mysterious magic spells that we all need to "conform to", isn't the whole concept where this started that we should adapt to what our teams need to operate at their best?

"Welcoming changing requirements" and "continuous attention to technical excellence" and "building things around motivated individuals - giving them the environment and support they need, and trusting them to get it done" - we should apply the same principles to the way we interact here. These are all great and valid ideas, if they will help someone do better, we should experiment and see if others will benefit too. It surely can't hurt!

Nic Brough -Adaptavist-

Welcome to the Atlassian Community!

You will never have the options you describe. Sub-tasks are not sprint items, they are a part of their containing story, and it is nonsense to have them in a different sprint to their parent.

And the whole point of Scrum is that you do not "assign a story to multiple sprints". If a story goes through multiple sprints, it tells you that the team has failed to deliver for some reason, and that needs to be investigated.

If you really want to have things in multiple sprints, then I strongly recommend that you actually stop pretending that your process is scrum-like, abandon the concept of sprints, and move to using something more Kanban (maybe with estimates if they are more useful to you than Kanban's throughput measurement)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira-software

jira-software-server

atl-orange