Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Best Approach for Subtasks for a User Story

 what happens if you have a backend task, UI Test, and Testing tasks under one User Story. The backend task needs to be completed before the UI work starts. All the tasks are under one User Story in the sprint. The Backend task is completed. The UI tasks will probably not be completed in that Sprint. How do you carry over the UI task for that User Story to the next Sprint?

 Is a good approach instead of creating Sub Tasks for a User Story. separate tasks for Backend and UI work?

Can you move a User Story between different sprints?

Can you move subtasks to different sprints?

2 answers

0 votes

Hello @Beverly ,

 

We using this kind of approach.

1. If any other tasks related to a Business requirement (Story) which not related to Dev & QA we creating a "Task" and linking this task to Business Requirement using "Issue Links". 

 

Or 

 

2. We faced an issue like as below.

We created multiple sub-tasks under a business requirement (story), These are not a part of DEV or QA. 

We have a condition as "If we have to close the story, All sub-tasks must be closed". When the sprint date is approaching, Many stories (Dev & QA) finished other items like Deploying, integration, and others are pending, due to these pending sub-tasks, every time we have to move to story from one sprint to another sprint. Due to this kind of operations we faced finding accurate Burndown and Sprint Velocity. Due to these blockers, we went with "1".

 

Or

 

3. If the sprint Deadline is approaching, many sub-tasks pending, You can create a new dummy story, and Move all these sub-task under it and add this story to the next sprint by calculating all these sub-tasks efforts. You can close the sprint with all the items are in the done state.

I don't know "3" is correct or not. Please consider it as an option.

 

Thanks,

Anvesh

0 votes

The most important thing to do when working with sub-tasks is to bear in mind what they are.  

A sub-task is a part of its parent story (issue). 

It is not a separate item, it is not a partner, it is not independent, it is entirely part of the parent.  Most importantly for discussing sprint - a sub-task is not a sprint item, it is a wholly contained part of a sprint item.

Remember that the point of a sprint is that it is a timebox.  You enter the timebox with a commitment (we'll do these stories listed) and leave with each story either complete or not complete and measure whether you delivered what you committed to or not.  Because sub-tasks are part of stories, you're not looking at them for commitment, only their parents matter.

In your sprint case, I don't know enough about how your teams work (or want to work) to be able to define whether you should be looking to split up the example in your story, or just work with it in one place.

But the sub-tasks are all part of the story.  That's very important to remember as I answer your list of questions individually:

>How do you carry over the UI task for that User Story to the next Sprint?

It's part of the story, so when the story goes to the next sprint, the UI task goes with it into the sprint

>Is a good approach instead of creating Sub Tasks for a User Story. separate tasks for Backend and UI work?

Possibly, it depends on how you are splitting the work up.  If you want to be able to say "Backed done while UI still needs work", then you will have to split the story into story-back-end and story-ui, with their component sub-tasks. 

>Can you move a User Story between different sprints?

Yes

>Can you move subtasks to different sprints?

Yes, but only as part of the story.  If you move Story X from sprint 1 (where all its subtasks are effectively in sprint 1 as part of the parent) to sprint 2, then all the subtasks go with it, and start being in sprint 2.

Thank You. I have an additional question about  Splitting up the stories?

Answer received:

Possibly, it depends on how you are splitting the workup.  If you want to be able to say "Backed done while UI still needs work", then you will have to split the story into story-back-end and story-ui, with their component sub-tasks. 

 Using this approach would I create two user stories. One User story for the backend with subtasks and another User story for the UI with subtasks?

 The backend work has to be completed before the UI work starts. Currently, I have One User Story with subtasks for Backend, UI Testing. When I start a sprint all of the subtasks will not be completed in one sprint. The only subtask that will be completed is Backend in the first sprint.

 

You can move User Stories to another sprint. Question:  can move a User Story that is in a sprint and the sprint has closed?

How do you handle a User Story with Subtasks that will span over multiple sprints?

 All the subtasks will not be completed in one sprint.

Yes, it does sound like you probably need to split the story into two - one for back-end and the other for UI.  This is not because it doesn't fit, but it sounds like there are two different teams that will be working on the groups of tasks.  A story really should be mostly done by one team (the idea is that a team can tackle anything, although in the real world, that means "anything in our field, and we might borrow people sometimes if there's something way off pitch")

And, definitely if one type of work has to be completed before the other.  That's a dependency.  Done within a single story, again it's down to "can the whole team deal with all the work" or not.  If it's two teams, you want two stories, one with a dependency on the other.

With Scrum, one of the important things is that the team does not over-promise on its ability to deliver something.  It needs to deliver something that moves everything forward, but if a story is too big for a sprint, that can't happen.  If a story looks too big for a sprint, it is.  Split it up into smaller stories that can be delivered as committed to.

Your stories should always be achievable within a sprint.  

Given a list of X that you committed to, it's not uncommon to not quite do it, and have some stories left over.  Those carry over into the next sprint, and are counted there.

You may have noticed I've not mentioned sub-tasks yet.  That's because they are a part of a story or issue.  They aren't really relevant.  The sprint, the velocity, the reporting, all of scrum is looking at the stories, not bits of them.

And to your last point "All the subtasks will not be completed in one sprint." - nope.  If you aren't able to complete all the subtasks in a sprint, then you're not completing what you committed to.  Your stories and/or sprints are the wrong size.  That screams "split the story up during backlog refinement"

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

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

Events near you