How to move only incomplete sub tasks to next sprint



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.

Hi, can someone point me towards where I could find the answer for this? I have the exact same issue happening currently. My potential solution is to break everything down into stories and remove sub-task altogether, but then I'm not sure how to then account for the QA estimations. Any direction to a solution is appreciated.

The answer is given above.  "You don't".  Sub-tasks are part of their parent, and it's the parent that moves from sprint to sprint.

The point of the scrum model is that you commit to something in the sprint, and you either "do, or do not".  There's no "done part", you've failed, and need to learn to plan/estimate better.

So Nic, it sounds like you're saying a developer who spent 10 hours completing tasks in a story "did not" do those tasks if, by the end of the sprint, the story was not completed and that developer is a failure.

One of the points discussed in this thread is Jira's inability to apply all hours burned in a particular sprint to that sprint regardless of the completion of the story.  If the 10 hours I mentioned above was burned in sprint1 but the story was not completed, those 10 hours get carried over to sprint2 with the story.  Reports will show those 10 hours spent in the wrong sprint.  In a simplified example: if a developer has 40 hours a week to burn (80 hours in a two week sprint), the report for sprint1 will only show he worked, or burned, 70 hours.  If he completes exactly all 80 hours in sprint2, sprint2's reporting will show he burned 90 hours.  You say we have to plan/estimate better, but how can you do that accurately when historical data (time spent) is inaccurate sprint to sprint?  Good decisions can only be made with good data.

As I mentioned in my previous post, I do not think it is unreasonable to expect to see hours burned in the sprint they were actually burned in.  I shy away from some of Jira's reporting because it is not accurate due to skewed data like this.  In fact, the reports are just plain wrong.  I have used VersionOne in the past and it reported burned hours accurately in a sprint.

No.  I'm saying your sprint has failed.

Again.  The point of the scrum model is that you commit to something in the sprint, and you either "do, or do not".  There's no "done part", you've failed, and need to learn to plan/estimate better.

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published Thursday in Jira Service Desk

How the Telegram Integration for Jira helps Sergey's team take their support efficiency to the bank

...+ reading Fantasy). The same is true for him at the bank he works for: Efficiency is key when time literally equals money. Read on to learn how Sergey makes most of the time he has by...

213 views 0 2
Read article

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