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
"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.
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.
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?
"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).
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.!
>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.
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.
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?"
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.
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.
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.
> 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.
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.
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.
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.
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.
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
>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.
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.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events