displaying velocity/burn down reports using story point estimates from child issues

[Jay Ruffell]

Hi,

I have been running a scrum project where we assign story point estimates to child issues of each story, but not to the stories themselves.  this has been useful for viewing the burn down chart during each Sprint (via the "Insights" tab on the sprint board) - we are a small team and typically only get through one User Story per Sprint,  so need something more granular than User STories to visualise progress.

However I have just tried to view the burn down and velocity reports for our previous sprints (via the "Reports" tab in the LHS sidebar) and these show no data, I believe because they ignore child issues.

Is there a way that I can display  story point estimates from child issues in these post hoc reports?  or alternatively, is there a different metric that I can use that will allow me to view progress of child issues on both types of visuals -  the one in the "Insights" tab during the sprint, and the one in the "Reports" tab after-the-fact?

Thank you!

P.S. I am in a team managed next-gen  project.

P.P.S. I understand  that assigning story point estimates to child issues is generally considered bad practice but  it seems to work well for us given that we only complete one User Story per Sprint

[Nic Brough -Adaptavist- · Accepted solution]

Welcome to the Atlassian Community!

In Jira, the "child" issues of Stories (and all the other issue types at the Story level) are "sub tasks" - you can have many differently named types of sub-task.

A sub-task is not an individual issue.  It is a fragment of its parent task, and can not exist without a parent of which it is a part.

As they are fragments of a larger item, they can not be treated as sprint items.  (Scrum does not mention sub-tasks beyond "if the developers might find it useful to create fragments of stories, that's fine, but a fragment is not a sprint item".  

For that reason, you can not put sprint estimates on sub-tasks.  All the estimation and completion reporting is done on the stories, and whether they are done or not. 

Imagine you have a story with 5 sub-tasks, each of which you've put 1, 2, 3, 4, and 5 SP, a total of 15 SP.

Your velocity is only measured against what you commit to doing at the start of the sprint.  Imagine you have several stories like the one above, then think about how the velocity is binary - is it done or not?

Issues you commit to the sprint	Story points added up from sub-tasks	Story points for the sub-tasks you complete in the sprint	Completion
ABC-1	15	0	0
ABC-26	15	6	0
ABC-45	15	14	0
ABC-82	15	15	15

Jira simply does not support not-scrum estimation like the one you are looking for.

The best solution might be to re-evaluate your layers - it sounds like your stories are really Epics (albeit small ones), and for a small team to have lots of Epics really is not a problem (for a larger set of teams, I'd create layers above Epic with Advanced Roadmaps or an app that can do it like Hierarchy for Jira or Structure)

There are schemes that people implement to "workaround" (or, more accurately, "bodge" not-scrum into scrum), and some apps enable some reporting, but these remain fundamentally flawed.   Atlassian have chosen not to implement anything at all, which makes sense to me, because of the sheer number of options that different customers might think they want.

The obvious one is "add the sprint estimates up on to the story using Automation", but that fails hard because you end up double-counting stuff in places.  If you are going to do sprint estimates on sub-tasks, then it is very important to do it with two separate fields, otherwise Jira is never going to be able to give you the reports you want.

[Ramon Reyes]

In short:

Child Issues and Metrics:
Unfortunately, Jira does not directly support displaying story point estimates from child issues in post hoc reports.

The burn down and velocity reports typically focus on parent issues (e.g., User Stories or Epics).
Consider re-evaluating your layers—your User Stories might actually be small Epics.

While assigning story points to child issues isn’t common practice, if it works for your team, keep using it for sprint planning.

i hope this helps!
myAARPMedicare

[Jay Ruffell]

Thanks for the reply Ramon! That is helpful. I ended up not tracking story points on subtasks, only for user stories/tasks, just because the post hoc reports work better that way. I sometimes still story point the subtasks as an interim step to getting a better story point estimate for the tasks/user stories, but then I delete the subtasks' story points and only track the tasks/user story story points so that the reporting works properly.

[Jay Ruffell]

Hi Nic,

Thank you for such a detailed answer and I take your point about the scrum team's output being judged on user stories rather than subtasks. It sounds like we need to make our user stories smaller so that they can be useful in the burn down chart.

I am still confused about if and how I should be estimating subtasks though. We are a new team with few previous user stories to use as estimation references, and so it works well for us to break down each User Story into subtasks, put some kind of estimate of effort/risk on those subtasks, and then roll those estimates up to provide the estimate for the User Story. Even if we did have lots of user stories as reference points I think the team gets value out of thinking about the subtasks involved and then tracking these through the Sprint.

Sounds like only the User Story estimates should be used for velocity/burn down, but I am wondering what I should do with the estimates from the subtasks – seems like it is throwing away useful information to just delete them once the User Story has been estimated. Do you have any thoughts on that?

Thanks,

Jay