How handle story with subtasks in different sprints?

[Steve Fogel]

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

[Deepanshu Natani · Accepted solution]

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.

[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]

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.

[Elias Hajjar]

so here is the catch,  if you were to rank every dependent story higher and to pull it into earlier sprint then you are doing "planning". Might as well planning the whole project and go waterfall :)

But in your defense,  the story should be "independent"  which is sometime is not the case. 

[Nic Brough -Adaptavist-]

No, that's wrong.

When you identify a dependency, you rank it higher than the things that it is blocking.  You don't plan the whole project, you're just putting an order on two items.

[Elias Hajjar]

i know that's wrong but i was bringing it up as an inefficient way to handle dependency.  a dependency can have dependency and so forth.  so where do you start? 

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?  

is this realistic?

[Sudarshan]

"the story should be "independent" which is sometime is not the case"

@Elias Hajjar This is like the chicken and egg case - who was first.! :D 

All the stories are connected to each other in a product/project in some or the other way.

In a sprint the meaning of an independent story is how smooth it can be made usable to the end user (no friction).! this working feature could be dependent on another feature which is under development.! and that is related to the product plan and release.

In an example: if we create a login page with UserID, Password and a reset feature (email).
(basic security)
The user expectation is a login functionality (this is a story, independent, testable)
Internally it is dependent on the server authentication, UI development, Unit testing.etc.) this could be done by a 2-member team (one is back another front, and an integration is needed) and these are sub-tasks.!

I am trying to give my understandings here, correct me if I am deviating.!

[Nic Brough -Adaptavist- · Accepted solution]

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.

[Heidi Fox]

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]

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."?

[Nic Brough -Adaptavist-]

Yes, that's a perfectly valid story. 

Not a well defined one for me, but that's simply because I have no information on the context in which it was written.

[Heidi Fox]

That doesn't really seem like something a "user" wants.  Users aren't supposed to care about implementation details.  But whatever.

[Nic Brough -Adaptavist-]

As I said, I don't have the context in which the story was written.

It doesn't really matter in this conversation though.  The point was about handling sub-tasks and breaking down stories when they're too large for a sprint - that's not done with sub-tasks.

[Elias Hajjar]

There are couple of topic on this thread. 1 at topic is story with stub-tasks but in deferent sprint. That's no no cos the story can not be complete in 1 sprint. U can't complete the story unless u complete the sub-tasks.

2nd topic is 2 stores with dependency between them and each in different sprint. That's acceptable if each of the story is testable and delivery value on its own. 

There is 3td approach in slicing the story. Vertical slice. Each item on the page is created standalone as a story. So u can create UX for use name and implement that as one story; and a 2nd story for user address Wich will have its own ux and dev in one story. Then u can create 3rd story to integrate 1st and 2nd. 

[Nick Giglio]

The answer is, again, Jira doesn't enable this.  There's no reason that you should not be able to stretch a sub-task across sprints along with its story.  This is an attempt for the tool to be prescriptive of the workflow rather than the tool accommodating the workflow.

Personally I want my Epic's to be feature for release.  I want my user stories under the epic to give additional context to the tasks and ensure that all dev decisions are made to accomplish the intent as described by the story.  As such I have tasks under stories that may be dependent cross sprint.  All tasks listed under the story should be made to accomplish the user story.  All user stories come together to create the epic

I don't need to release code every sprint, but I do need to formally regroup, thus the use of Sprints vs a Kanban approach.

But the tool doesn't allow that.

Don't tell people they are running their teams wrong.  They are running them in the manner which works best for their product needs.  They could potentially change things to work differently but stating the limits of the tool as the user performing their processes incorrectly is simply incorrect.

[Nic Brough -Adaptavist-]

> There's no reason that you should not be able to stretch a sub-task across sprints along with its story.

Um, ok, that's not right.  It completely misses the point of doing sprints, and if you're going to do that, then you should stop pretending that you're doing Scrum.  

The tool does not support doing things this way because it is a tool designed to support scrum, and this it absolutely not doing Scrum.

I'm not telling anyone they're running their teams "wrong".  I'm just pointing out that they're not doing scrum, and trying to use a scrum tool to do it.  That is not going to work as well as you might like it to.

[Nick Giglio]

Personally we don't pretend we're doing pure Scrum as it isn't conductive to our environment or workflow.  That said, sprints are very useful.  

This is the correct answer and something that needs to be said louder, but saying it is bad marketing...

Jira Scrum Projects require a pure scrum methodology and do not enable much flexibility.  If you utilize a hybrid methodology or seek to define pieces in such a manner, this is the wrong tool.

The team isn't wrong.  The tool is.

[Nic Brough -Adaptavist-]

I think we totally agree on that.

I think I have a bias when talking about it that I continually run into teams who say "we're doing scrum" only to find out they really really are not, because they don't see carrying over issues from sprint to sprint, putting sprint estimates on non-sprint items, or including status that the team can't work on, as wrong (wrong in scrum, not their process).  

The team here still has something wrong, not the tool.   Their choice of tool is the wrong bit.  They've chosen a hammer to get a screw in.  It'll do the job, but it won't do it the way your screw expects because it's a tool built for getting nails in.

[Helen Ioffe]

how do you handle the case when the user story is completed and tested with the sprint and accepted by the product owner, but it is not yet promoted to the  RC (release candidate environment) because release backlog and the sprint backlog are two separate things? you can have several integrated environments and not everything will need to be deployed to the release candidate environment. The smart way to do it would be keep the sub-tasks left on the user story indicating that... what are other suggestions here? i really would like to avoid creating additional standalone tasks to keep track of release candidate activity/retest. 

[Nic Brough -Adaptavist-]

I have to go back to the simple "is it done or not" question.  Does it need more work?  

[Helen Ioffe]

it needs to be regressed in another environment 

[Nic Brough -Adaptavist-]

But does it need more work?

[Oscar]

I thought tools and applications exist to satisfy the needs of their users, not the other way around. It's the first time I see a company refuses to satisfy the needs of its customers just because you think they're doing it wrong, The fact is that we're doing it as we can. And if Jira was a good tool, it would adapt to the needs of both the purists of Scrum and the ones who use a hybrid approach. Out of your perfect world, the latter is a larger group than the former. And refusing to satisfy our needs tells me your tool is wrong, not your customers.

[Nic Brough -Adaptavist-]

That's the point - the need of the users who have chosen Jira Software is to do Scrum.  Variants, yes, but not doing stuff that makes it totally non Agile and unmeasurable.

It's not about purism (if it were, you simply wouldn't have sub-tasks in Software projects).

[Nic Brough -Adaptavist- · Accepted solution]

>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.

[Sudarshan · Accepted solution]

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 · Accepted solution]

As @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

[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? 

[Nic Brough -Adaptavist-]

It is what you answered, yes.  I tried to suggest some ways to work around the broken way the questioners were working, but my suggestions all fit within your original answer (I hope.  If they do not, then I've explained it badly)

[Nick Giglio]

Nic, the questioners aren't working in a broken  manner.  They are working in a different manner which the tool doesn't accommodate.  The request is for the tool to accommodate and at the moment the answer is that the tool doesn't want to accommodate that.  If that's the case, state it plainly so that users can identify the tool which best meets their workflow.

I prefer to keep those tasks under a single story as they're part of the same user need and my stories come out of user needs.  Then they tie together under larger epics.  I could use initiative -> epic -> task instead and eliminate this but we utilize initiatives at a cross department level.

I can accomplish my exact needs utilizing Tasks vs SubTasks under Stories but now the actual work isn't attached to the user need which is the point.  The Epic ties nicely to marketable features which are wholly completed.  

[Nic Brough -Adaptavist-]

Mmm, I think you've missed the point here.

Their way of working is broken if they think they're doing scrum.  The tool is a scrum tool.  They're not doing scrum, so it's broken.

[Rajesh Viswanathan]

Thanks for the good discussion's