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 votes
Accepted answer

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.

Over time, the velocity of the developer/team will average out anyway, so if you don't need the hours worked to be accurate to the T for client billing purposes or the like, then bringing all completed subtasks over to the next sprint with the uncompleted story works out in the long run.

Real World Agile -

There are a number of factors and an incremental path to get to Scrum nirvana - black and white scrum out the gate is for the lucky few.   CI/CD, maturing roles - especially with POs and teams  that are just getting their feet wet with automation struggle with some of the limitations in Jira.   There are ways around it all - but sr. leadership many times can't see the velocity through the trees and enterprise agility and business agility are terms just recently coined - not even in early adopter phase 

Estimating hours on Sub-Tasks is a false God, Parkinson's Law "Work expands to fill the available time" - a  human factor.  Pretty logical.  Waste to remove.


  • Create stories and slice them to what you think you can deliver in the sprint
  • Understand what points are and use them for story level estimations - I sometimes use tee-shirts for epic
  • Sell the concept of not adding hours to sub tasks - the meat of the task is the value - not hours.  This is waste
    • If you are back billing work, figure out the % of your 40 week spent on client sprint stuff and allocate accordingly.  This will be a better estimate then toiling over how much time it will take add a line of code or get your PR done or whatever.
  •  If you don't finish, move the story - leave the points as is - Velocity is an average over a number sprints.  Somebody up there mentioned this already.
  • Understand that if you move a story that has completed work - your SM and those doing the work need understand that there is more bandwidth than what appears in those Jira reports- plan accordingly.  **this drives SMs crazy - but it is what it is.
  • Strive to get to Scrum Nivana someday for most - its a many sprint journey with lots of incremental change along the way - you may have to play the game with some caveats as you mature - but that's reality

Talking to Agile scrum teams this works great and truly make sense and is the correct thing to do.

For me - i have Waterfall or not pure agile Implementations as well and i want to leverage the Agile boards for teams that are not  agile but can benefit from using the scrum boards and working in sprints - and the current behavior makes  me search for creative solutions time after time as in non agile companies stories are not always completed or in a size of a sprint but subtasks are completed within a sprint.

It's the same answer as above - you're not taking the sub-tasks anywhere.  Their parent is the thing that is in the sprint, and takes all its subtasks with it.

@Lori Garduno Thanks for your insight Lori.  I am on the same page with your recommendations, but the one issue I still have is the lack of ability to account for hours burned in a sprint that do not appear in Jira reports for that sprint if the story was not completed.  I agree if a story is not done, it should be moved to the next sprint with its points.  Incomplete is incomplete.  However, whatever time was spent and burned should be attributed to that sprint.

I understand what you're saying about trying to get away from tracking time, but it needs to be tracked for some of the projects I work on.  Your one bullet point about the "need to understand there might be more bandwidth than appears" gets difficult in large organizations that might be using a scaled agile approach.  Consider architects that work with several teams.  They need to allocate their time appropriately and it would be very difficult for the scrum masters to know that resource's real bandwidth when the numbers are so wrong.  If Jira was accurate, it would eliminate the guesswork.

My argument is if Jira simply credited the time burned in a sprint to that sprint, it would allow accurate reporting and eliminate the need to compute actual time worked in a spreadsheet or some other method.  I really don't understand how this is acceptable.  If this was a financial tool we would expect it to be accurate and not show income or expenses incurring in the wrong time period.

Projects I am working on now need the ability to track time so they can be charged to the appropriate project budget.  We have some people that work across teams and need to track time spent per project.  Jira skews the time tracking numbers and now some here are considering implementing some kind of time sheet application, like another Jira add-on or other 3rd party app.  This extra work and expense can be eliminated if Jira simply reported time tracking accurately.

One can argue about proper planning and I get that.  I totally agree with better planning, but if that is the solution to this Jira shortfall, I would ask how do you plan when the team is working with inaccurate data?

At the very least it would be good to know if a ton of time was spent during a sprint but few stories were completed.  These are situations where improvement is needed.  The team can look at the numbers and start to ask questions and try to figure out what issues they are encountering that are preventing them from completing their stories (great retrospective topics). But as of now, Jira reports would just show the few completed stories and the little amount of time spent on them.  Simply inaccurate data.

I agree getting to Scrum Nirvana is a struggle and journey.  This issue with Jira is a thorn in my side and solving it would make the journey just a little less bumpy.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Jan 08, 2019 in Jira

How to Jira for designers

I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...

1,088 views 4 9
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