Why does sprint burndown using issue count ignore sub-tasks as issues?

[Brian Milner]

I've read and seen the arguments for and against tracking story points within a sprint vs hours.  However, there are many Scrum professionals out there (myself included) that disagree with tracking hours at all using Scrum.  Doing so begs the question from the team and stakeholders of how many hours equal a story point.  The Scrum Guide does not tell you to use hours to estimate tasks within a Sprint so it seems strange for Atlassian to take this strong stand.  My take is that Story Points are used for planning outside the sprint or for more longer term planning (release planning).  Within the sprint though, there needs to be some other measure of progress.

The purpose of using a Sprint Burndown chart is to provide the team with a daily picture of the team's progress so that they can adjust accordingly to meet their sprint goals.  Using story points only has the "cliffhanger" effect in that stories can take several days to make it through all development and testing activities.  What you get in those cases is a straight line with sharp drop offs mid way through sprints to show the story being completed.  This is not effectively helping the team track their progress daily.

We looked for a way to do this in Jira other than using hours for the reasons mentioned above.  We noticed recently that you can change the Sprint Burndown chart to reflect when issues count is decremented.  This seemed like a good solution, while still somewhat inaccurate as all issues would be weighted equally.   We tried this but soon discovered that when Jira says "Issue Count," they do not treat all issue types equally.  Specifically, sub-tasks are worthless.  The issue count burndown only looks at issues of type Story/Task or higher and ignores sub-tasks.  This makes using issue count worthless.  

I put this out to the community to see if anyone else has found a way around this issue?  We are open to using any alternative measure of tasks inside a sprint other than hours.  We want all issue types to show progress on the burndown so that our teams can see overall progress more accurately on a daily basis.

[Jessie]

Hi Brian, have you had any updates to this question? I am in a similar boat right now where I want to use issue count burndowns but include subtasks in them and am struggling. 

[Walter Buggenhout]

Hi @Brian Milner,

This is a really much discussed topic. A good thread to check out might be this one, where a lot is explained about why this is the way it is, arguments representing opinions for and against, links to additional information and even the odd suggestion for a workaround.

[Danut M _StonikByte_]

Hi @Brian Milner / @Daniel Mello ,

The latest version of our Great Gadgets plugin offers this. The sprint and release burndown gadgets have an option to include sub-tasks, which you could use to achieve this.  The plugin is available for both Jira Server (https://marketplace.atlassian.com/apps/1218777/great-gadgets-for-jira-server?hosting=server&tab=overview) & Jira Cloud (https://marketplace.atlassian.com/apps/1216564/great-gadgets-for-jira-cloud?hosting=cloud&tab=overview). 

Danut.

[Daniel Mello]

I'm also looking for an update on this. I need to consider sub-task and technical tasks throughput not only from stories but bugs and other types of issues as well.