It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Modifying Burndown Chart to show Sub-tasks instead of Story points

The Burndown Chart Shows Story Points vs. time.

How can I modify the y-axis to plot sub-Task estimates as well.

4 answers

Unfortunately you cannot. This is because on plan mode you do not see the sub-tasks, which means you only estimate story points on parent stories.

If you want to include sub-tasks estimates into burndown charts, then my recommendation would be to move away from story points to original time estimate as your estimation statistic.

Once you do this, the burndown chart will burn down time instead of story points adn therefore it will take into account the time estimates you logged for sub-tasks.


@Rahul Aich [Nagra] - thanks for the reply smile

I'd like to have a Burndown Chart which depicts the number of sub-Task on the y-axis.

That is, I wish to see the total number of sub-Tasks on the y-axis instead of hour(time)-values.

Do I need to write my own plugin to achieve that or is it possible to tweak Agile somehow to get this result?

Unforutnately you cant, you would need to write your own custom plugin for this. Rahul

I think we have a valid use-case for this behavior. We have a short sprint (due to externalities) and a dense commitment. There is a lot of work going on and for most of the sprint no story will close. The team weighed the risks.  We made a calendar for the sprint and we believe our commitment is do-able, but we want to know if we are on track from day one.  A sub-task burn down will let us know more quickly if the sprint is progressing as planned.

The tool isn't supposed to dictate the process. We will create our own burn down. In the future the tool should support what the team requests.

Like Erin H. Kimmons likes this

I think we really need to resolve this. Burn downs based on sub-tasks is standard practice in the industry. I realize it must be frustrating if you are working with an older version of JIRA, but I would say this is pretty basic need which. Its 2016 and there's really no excuse to not have this. If it is missing it is creating a lot of risk for the organization by either disallowing the reporting of daily, sub-story progress or by forcing teams to use non-standard and confusing practice of a high level estimate without story points.

Like Eoin O'Kennedy likes this

You can help yourself a little if you only estimate subtasks and use the default behavior where stories are the sum of the subtasks' SPs. Same with Epics that total all the stories.

You could even run a background job in ScriptRunner that scans for any unestimated subtasks and sets them to default of 1, meaning they're basic tasks. That will result in everything having an estimate and the burndown chart working as intended.

Be warned subtasks are not reflected in Epic reports or Release reports

Guys, this is my first post within this community... :)


I had the same question within my project and build a solution for us. Just check that blog post and see if it fits your needs.

Thanks a lot for that solution! (y)

I'll try that - for my team the typical cliffhanger burndowns is a big problem, too. Currently we have to workaround this by Excel burn down charts :(

Viele Grüße von der Ostsee,

My strategy with my team is User stories in Story Points and Sub-task in Hours.

User stories in SPs are the relative measures and  primarily used for velocity and future estimates. And T-Shirt sizing method is used for estimating Story Points (SP) for the user stories.

However it is more realistic to use Hours estimate for Sub-tasks or tasks under User stories. In this case User stories are in SPs and sub- tasks are in Hours. Almost most of the organization using this hybrid approach.

for Burndown hours, JIRA is difficult to use? Almost of the time i export all the issues to excel and create chart based on that.

Like Eoin O'Kennedy likes this


  1. make sure your filter query in the Board also includes 'sub-tasks'
  2. Enabled time tracking
  3. Configured estimation and tracking:
  4. all your sub-tasks are added before sprint start date, time

Thanks! This reply helps us a lot!

We learned from Dirk's post and took a slightly different approach: We added post-functions to our Create, Done, Close and Reopen transitions in our Sub-Task workflow to update a custom field called "Open Task Count":

We use Story Points as our estimation statistic so that we can track velocity sprint over sprint, but we can choose Open Task Count on our Burndown Charts to view progress during the sprint.
Vote up if you'd like to see the option for a custom field added to the Sprint Burndown gadget.
Thanks !

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.event.type.EventDispatchOption
import com.atlassian.jira.issue.CustomFieldManager
import com.atlassian.jira.issue.fields.CustomField
import com.atlassian.jira.issue.ModifiedValue
import com.atlassian.jira.issue.MutableIssue
import com.atlassian.jira.issue.util.DefaultIssueChangeHolder
import org.apache.log4j.Category
if (issue.isSubTask()) {
    MutableIssue parentIssue = (MutableIssue) issue.getParentObject();
    String customFieldName = "Open Task Count";
    def customFieldManager = ComponentAccessor.getCustomFieldManager()
    CustomField cf = customFieldManager.getCustomFieldObjectByName(customFieldName);
    DefaultIssueChangeHolder changeHolder = new DefaultIssueChangeHolder();
    def User = ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser();
    double currValue = (double)cf.getValue(parentIssue);
    // create, reopen
    // Double newValue = currValue + 1
    // done, close
    double newValue = currValue - 1
    ComponentAccessor.getIssueManager().updateIssue(User, parentIssue, EventDispatchOption.DO_NOT_DISPATCH, false)

(a crude hack - comments gratefully accepted)

(edited to replace the call to updateValue(), which updates the value, but doesn't update the change history, with a call to setCustomFieldValue(), which updates the value, and updates the change history, upon which the burndown depends)

(further edit to say that:
1) You should zero out the Open Task Count in a post-function on the Story Create transition, so that cloned Stories won't inherit the Open Task Count value. 
2) Moving sub-tasks to different parent Stories will not be accounted for by this method.  If anyone has a good idea how to handle this, I'm all ears. Thanks)

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Jira Software

Early Access: If you use Jenkins and Jira Software Cloud, you need to read this!

The Jira Software Cloud Team has been busy working on a simple, secure, and reliable way to integrate your build and deployment information from Jenkins with Jira Software Cloud. This means you don’t...

703 views 0 11
Read article

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you