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

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.

2 answers

1 vote

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.

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. 

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Tuesday in Statuspage

Introducing Statuspage Getting Started guides! First up: What is Statuspage?

Over the next several weeks we'll be sharing some of our Getting Started guides here in the community. Throughout this series of posts, we'd love to hear from customers and non-customers ab...

203 views 4 1
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you