Hide subtasks on Active Sprint view but include subtasks estimations in the burndown chart

[Rachel Hart]

Ref: Software Project/ Company-managed/ Active Sprint board
Hello,
I've been researching a way to NOT display subtasks at the active sprint board, which I was able to do by creating a filter query below, however, I read in the community pages that by hiding the subtasks would cause for the subtasks estimates to not be included in the burndown chart. I can't find this in the documentation.

Is that true? Can someone point me to documentation that prove one way or another?

If so, how can accomplish hiding the subtasks on the active sprint page and accounting for the hours at the burndown chart?

Query:
project = MB AND issuetype in standardIssueTypes() ORDER BY Rank ASC

[Mykenna Cepek · Accepted solution]

Your query is a good way to exclude Sub-Tasks from showing. You can use it on the main board filter, or even as a Quick Filter (to toggle it on/off on the same board).

However, I'm pretty sure that pointing Sub-Tasks isn't a thing in Jira. You can do it, but they don't factor into metrics or reports. Sub-Task points do not roll-up to the Story.

AFAIK, Jira is built to focus on points for Standard Issue Types (Stories, Tasks, Bugs, etc) only, and not with Sub-Tasks.

I just did a test (in Jira Data Center, not Cloud) showing that pointing a Sub-Task doesn't impact the burndown report at all. Only points on Stories are reflected in that report.

This is likely true for other points-based metrics throughout Jira as well. For example, when I look at the Sprint in the Backlog view, and see the points totals (To Do, In Progress, and Done) in the top-right corner for that Sprint, only the points for Standard Issue Types is included - points for Sub-Tasks are ignored.

For good or bad, Jira just isn't interested in Story Points on Sub-Tasks. Confusingly, it doesn't prevent you from configuring them to show on Sub-Tasks, but they aren't integrated into other metric measures.

If you're very intent on assigning points to your Sub-Tasks, you could look at using Automation to aggregate the points in all the Sub-Tasks to overwrite the points on the parent Story. Not recommended either, but it can be done.

[Rachel Hart]

Hi Mykenna, we estimate in hours at the sub-task level and the total gets rolled up to the parent level. 

[Mikael Sandberg · Accepted solution]

Hi @Rachel Hart,

Welcome to Atlassian Community!

Correct, in order for the subtask to count towards the burndown chart it has to be selected by the filter the board is using. If you remove the subtask it will not count, nor will it roll up to the story/task. the board will not consider subtasks that are not visible, the same applies to issues that are not selected by the filter.

You can take a look at Understanding the Burndown Chart and Estimate an issue for more information. 

[Mykenna Cepek]

I believe this is true for the time estimation fields for Sub-Tasks (estimated, remaining, original estimate), but not for points.

[Rachel Hart]

We estimate in hours at the sub-task level and the total gets rolled up to the parent level. 

[Rachel Hart]

@Mikael Sandberg Is there any way you can recommend I can configure to have the clean look on the active sprint board which means excluding subtasks and rely on burndown? Or would the only way be estimating in hours or points at the parent level?

The reason we like the sub-task estimates in hours is because we are using the capacity planner add on, this help us get more accurate in planning our workload per resource.

[Mikael Sandberg]

As @Nic Brough -Adaptavist- mentioned below, the only option would to not use subtasks.

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

Your question is a good one, but it's born of something deeper than just the reporting and views.

The short answer is that you have a broken process.  Sprint estimates do not go on sub-tasks.

In Jira, a sub-task is a fragment of a sprint item (story).  It's not independent of the story, it's not related to it, it is a part of it.  It's fine to put some form of estimate on a sub-task, but that estimate is completely irrelevant to the sprint (or throughput if you move to Kanban).  

To solve your problem, you don't need to be looking at the reporting or views, you need to 

a) Do Scrum "properly" (Scrum has nothing to say about sub-tasks, it only talks about sprint-able items.  Sub-tasks are not sprint items, so Jira's Scrum boards ignore them.  The short version of that is "don't put sprint estimates on sub-tasks")

b) Build a summation strategy based on "sub-tasks are part of a story", and script or automate something that lets people put estimates on the sub-tasks and have the data roll up to the stories in a different field, so that field can be used as the sprint estimate.

[Rachel Hart]

Hi Nic,

Thank you for bringing this up into a broader perspective. Regarding what you mentioned on "script or automate something that lets people put estimates on the sub-tasks and have the data roll up to the stories in a different field, so that field can be used as the sprint estimate." -- could you please elaborate a little more on the last part "so that field can be used as the sprint estimate."

[Nic Brough -Adaptavist-]

Yep, my writing was not intended as a "perspective" or opinion, it was more aimed at explaining why Jira doesn't work the way people expect it to in this case (it's usually because they don't quite "get" Scrum/Kanban/Agile processes). 

Atlassian don't have a lot in their docs or tutorials that explain that they've gone with the most simple implementation of Scrum they can (simple means giving us the flexibility to build on it any way we want), and there's not a lot about just how subordinate sub-tasks are.

So, when we want to put estimates on sub-tasks (which, I think can be very useful, despite all the Scrum principles being beaten into me over the last 25-ish years), we need to look at a strategy to implement something in our tooling.

For Jira, the sub-task is very much a part of the parent, they're not sprint items.  Jira uses one field for the sprint estimate, which means that if you just try to use a single field, you get into a mess because parts of Jira look at the estimate on sub-tasks and other bits do not.

The core of the solution is to split the estimation into two parts, and automate one from the other.

Let's say you want to do sprint estimates on Story Points. Rather than just point your board at the Story Points on all the issues, do this:

• Have a field that people can enter, on all issues and sub-tasks (let's call it "Charlie")
• Have a numeric field (let's call that "Alice") on the issues, but not the sub-tasks
• Write an automation/script/app/etc that calculates Alice from all the Charlies on the issue and its sub-tasks.  Point your Scrum estimate at Alice, not Charlie.

Whatever you do here, have a think through which calculation scheme might work best for you.  Some things to look at when looking at schemes are:

Are your sub-tasks definitive?  Do you always have sub-tasks (even if it's only one) that contains the effort?  (In Jira, you you put Charlie on the stories, and include it in the calculations of Alice?)

• The most simple scheme is to just have "Alice = Sum of all Charlies" on the issue and its sub-tasks
• One that works better for people who do a lot of refinement is to have the Charlie on the main issue reduce as sub-tasks are created.  (For example, someone creates a story with Charlie = 8.  When people create 3 sub-tasks with Charlie = 1, 2 and 4, the Charlie on the parent task drops to 1, but Alice remains at 8 because it's the sum)
• And
• And
• And

There's lots of ways to do this, but they do all affect the way you do scrum.  You should pick the best one that works for you and configure Jira to support it, bearing in mind that, off-the-shelf, it only really supports plain Scrum (without sub-tasks)