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-

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.