How to move only incomplete sub tasks to next sprint

Hi,

Situation:

Lets say I have one parent and 4 sub tasks in it. In the sprint I was able to complete only sub tasks.

How do I move only renaming 2 sub tasks. - Manually?

Also How to i estimate story with 2 sub task - Manually?

 

What are the best ways of doing this?

2 answers

1 accepted

0 vote

You don't.

A sub-task is part of a parent issue.  That issue should remain open until all the parts of it are complete, so all of it goes into the next sprint if any part of it is incomplete.

So I have to reduce efforts on the parent story manually as some of the sub tasks are already closed in previous sprint?

Also how to i track efforts spent in each sprint for one user story?

Yes, it's part of the reason we generally recommend "do not estimate subtasks"

Thank you for quick response.

So I don't have to reduce story point in next sprint? If yes, then e.g. that story left with 1 point work however original was 4 then next sprint will have 3 points no work.

Yes, you need to do that too, if you estimate subtasks.

Ideally, what you should do is not adjust anything.  If you don't finish a story in a sprint, it goes into the next sprint along with all of its estimates.  That's it.  If you find that happening a lot, you need to look at splitting your stories up or making better estimates.

There is a discussion to be had about putting estimates or story points on subtasks or their parents, but it simply can't work if you do both.  JIRA Software only really supports estimates at the parent issue though.

 

Jack Brickey Community Champion Apr 28, 2016

@Nic Brough [Adaptavist], can you elaborate on your last statement "JIRA Software only really supports estimates...". I don't quite follow your point.

What we typically do is to not estimate the parent in favor of placing estimates on the sub-tasks leaving the parent (story/task) to be a container requirement/milestone/etc. JIRA will then allow you to "include sub-tasks" in the time tracking for the parent. We also use Due Date on the story. In this manner we can create dashboards that show the story, w/ due date and the Σ Progress field to show the collective progress on the story. Most of our audience for dashboards don't care about the details (sub-tasks) but do want to see progress on the milestone (parent).

With that said, and more to the point of this thread, the one thing that does drive me crazy about JIRA is the inability to assign sub-tasks to a sprint w/o moving the entire story into the sprint. Sure I could use Epic but I don't consider an Epic to equate to 2-3 two-week sprints in my world. And, as you point out, I could break the larger story into stories that could be done w/in a sprint, however, that doesn't always work or make sense if I want the story to be something that is deliverable/functional/testable, i.e. stands on its own.

The bit about the estimates is more about story points (they don't roll up to the story level, unlike estimates, which are at least shown with the parent).  But a lot of people want the rolling up to work one way, and other people another, and the largest set of people can't even decide, coming up with half a solution and an inability to cope with either. 

However, because you're using estimates, you're in a better position than the story-point users because you do have the roll-up and you've taken the correct stop of only estimating on one level (sub-task).  This will work fine for you, it's not broken in this case.

>inability to assign sub-tasks to a sprint w/o moving the entire story into the sprint
That's because it's the wrong thing to do.  Agile can't accurately record velocity or progress if you don't move the whole story.  If you want it to work, then split your stories up better, and continue to use

Jack Brickey Community Champion Apr 28, 2016

thanks for the reply Nic and now I understand and this is why I use time vs. story points. Also agree on the sub-task bit as it relates to velocity, etc. however, the option to do this would be useful as for some teams these reports are not as critical. in any event there are work arounds that i employ today.

Hi @Nic Brough [Adaptavist]

On this note, If the story isn't complete in the sprint, but some of it's sub-tasks are complete, Moving the story to the next sprint will also make the closed sub-tasks inherit the Sprint field value and it will be changed to the new sprint, But the fact is that the closed sub-tasks are done, it makes no sense updating the sprint value. Do i have a way to overcome this?

There's nothing to "overcome".  The story moves to the next sprint because, by definition, it's not complete.

This seems to be a common question and I too am struggling to find a solution.

My team puts points on stories and tracks hours in sub-tasks.  We track sub-task hours so that we know what types of tasks the team is spending time on.  We can see how much time goes to dev, qa, etc.

If a story is not completed in a particular sprint, it is carried over to the next sprint (this is fine and what I want to happen).  All of the sub-tasks, including the completed ones, are also carried over to the new sprint.  The problem is any hours burned in the sub-tasks from the previous sprint do not get "credited" to that sprint, but instead get included in the new sprint.  So for example, if a developer burned 10 hours in Sprint1 and has 3 hours left to complete for Sprint2, the 10 hours he spent in Sprint1 do not appear in Sprint1 reports, but instead get added to hours burned in Sprint2.  If planned capacity for that developer is 30 hours/week, then it will look like he spent 20 hours in Sprint1 and potentially 40 hours in Sprint2.  It screws up all sorts of reporting and metrics.

What we have resorted to, and I hate it, is if a story is not completed by sprint end we adjust story points and delete any unfinished sub-tasks.  Then we create a new story for the next sprint that includes the remaining points and hours.  Now at the end of our sprints it looks like we completed 100% of planned stories and tasks and is not an accurate picture.

I am looking for a solution where whatever sub-tasks completed and hours burned in Sprint1 get credited to Sprint1. VersionOne did this easily when I used to use it.  I don't think it is unreasonable to expect to see hours burned during the sprint they were burned in.

I would appreciate any suggestions.

 

 

Jack Brickey Community Champion Jul 28, 2017

@Pete SpadaroI believe this has already been answered and your method is as good as any but as you mentioned 'ugly'. I lived thru this for some time and worked to improve our estimating and broke stories down into as small as possible which, in my case, worked 95% of the time and this was certainly acceptable to me.

You may want to peruse the JIRA product suggestions to see if something is out there for this and vote for it.

@Jack Brickey Thanks for the reply Jack.  I am glad to know others struggle with this (unfortunately) and I will take a look at the JIRA product suggestions as you mentioned.

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,338 views 14 20
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot