nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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?

Accepted answers

Nic Brough -Adaptavist-

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.

All comments

Nic Brough -Adaptavist-

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"

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.

unknown

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.

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!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software