How to move only incomplete sub tasks to next sprint

[Paresh Gandhi]

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?

[Nic Brough -Adaptavist- · Accepted solution]

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.

[Paresh Gandhi]

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

[Paresh Gandhi]

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

[Nic Brough -Adaptavist-]

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

[Paresh Gandhi]

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.

[Nic Brough -Adaptavist-]

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.

[Paresh Gandhi]

got it thanks,

[Jack Brickey]

@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.

[Nic Brough -Adaptavist-]

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]

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.

[Shirley Jhirad]

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?

[Nic Brough -Adaptavist-]

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

[Pete Spadaro]

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]

@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.

[Pete Spadaro]

@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.

[Deleted user]

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.

[Nic Brough -Adaptavist-]

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.

[Pete Spadaro]

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.

[Nic Brough -Adaptavist-]

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.

[Deleted user]

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.

[Lori Garduno]

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.

Recommendation 

• 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

[Shirley Jhirad]

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.

[Nic Brough -Adaptavist-]

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.

[Pete Spadaro]

@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.

[Derek Rone]

Our shop needed these metrics, not every shop runs Agile in its purest form so you make it work.  I created a Post Function for our Sub-Task workflow that captures the Parents "ACTIVE" sprint (if it exists) and populates a custom field.  This gives us a measure to report on.  

def SprintCompleted = null
def parentIssue = issue.getParentObject();

if (parentIssue.get("Sprint"))
{
switch(parentIssue.get("Sprint").size)
{
case 0:
SprintCompleted = null
break
case 1:
if(parentIssue.get("Sprint")*.active)
SprintCompleted = parentIssue.get("Sprint")*.name
break
default:
parentIssue.get("Sprint")?.each {
if (it.state.toString().contains("ACTIVE"))
{
SprintCompleted = it.name
}
}
break
}
issue.setFieldValue("Custom Field Name", SprintCompleted)
}
else //No Sprint on Parent
SprintCompleted = null

if(SprintCompleted == null)
issue.setFieldValue("Custom Field Name", "No sprint associated to parent")

[Shwetha_Peruri]

Hi @Derek Rone , can you please elaborate on the above function.

[Nic Brough -Adaptavist-]

It's a botch which creates a parallel sprint process that will not work.  It creates a field that lies about whether a sub-task is in a sprint or not.

[Derek Rone]

It worked for what we used it for, since our last post we have switched over to measuring velocity so we aren't using this custom field for tracking the completion of a sub-task.  I have always enjoyed ready Nic (for years now) and how blunt he is on his answers.  Cracked me up most the times...I feel like I have my finally made it now as a Jira admin knowing Nic doesn't agree with me!  Thanks Nic!  No sarcasm implied!