Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Burn-down to include sub-tasks

Article by: 

@Gautham Hari and @Robert Nadon 

In true agile methodology, burn-down charts burn down entities to show true progress towards reaching the end goal of completing the sprint or epic. In as much, this ideology means that only completed releasable stories and tasks are included within the burn-down chart. Subtasks are not included as the theory behind a subtask is that it is part of a solution and cannot be released without the parent and all other associated subtasks being released, and hence should not appear on the burn-down chart.

That is the philosophy and true agile methodology. However, we live in the real world and some companies want a chart to show how much effort has been included by giving a total issue count including subtasks. Even with the use of story points and the like the values from the subtasks are ignored. However, it was brought to us the desire for a burn-down chart to be an accumulation of all issues be it task, story, or subtask as they did not use estimation and wanted only a burn-down of completed issues. This article will outline the novel solution we found to accomplish this using only built in Jira, JSM, included automation, and tools. No extra plugins are needed to implement this solution.

Given each issue should count as a point ignoring the type of issue we decided we needed to find a count for each (non-subtask) issue that would include both itself plus every non “done” sub-task attached. By non “done” we are referring to any issue that is not in the status category of “done” such as Closed, Done, Cancelled, etc. The reporting tool itself for burn-down can include various fields along with a numerical custom field of our creation. So we created a numerical field we will call “Total Issue Count”, and did not put it on the view screen as it was not something we want to display to users. Also this field would only be on non subtask issue types.

Using Automation we set this field as follows:

    • At first we set it to add 1 to the current value but ran into problems when the issue was cloned as it would grab the current value and add 1 to it. So hard coding to 1 fixed this problem.

    • Furthermore, there is never a case when an issue is created that it already has subtasks, as to create a subtask the issue must already exist.

  • When a subtask is created, automation will add 1 to the parent field of “Total Issue Count”.

  • When a regular Issue is closed the count is reduced by 1.

    • If an issue were to be deleted it cannot have subtasks (Jira is smart enough to check for this) and since it is deleted this case can be ignored.

  • When a subtask is closed the parent count is reduced by 1.

  • When a subtask is deleted (and its parent exists) the parent count is reduced by 1, unless the subtask is in the done status as that would decrement it twice. (This was something caught after initial implementation)

  • When an Issue is reopened the count is increased by 1.

  • When a subtask issue is reopened the parent count is increased by 1.

Now we ran into another problem in that when using rules that state checks such as “Issue Closed” and “Issue Reopened” as those triggers are based upon Events. Using the standard workflows or even creating you own you can go into the post functions and notice that all but the create issue fire a generic event. So unless you go in and correct this to where it would fire a “Issue Closed” event on the the transition to closed (I recommend doing this anyway), the solution could be multiple. Since the customers workflows only used one “done” status for all workflows where we were using this automation we chose to fire when transitioning from any status to the “Done” status.

NOTE: If you have multiple “done” statuses such as Closed and Done and can transition between them, for example, if either status have all → transition, you will need to account for that instead of leaving from blank, choosing all non done statuses.

From here we have tested the automation and everything seemed to work, so the next thing was this would only work for issue going forward. All issues that were out there before the automation was turned on would not contain a correct value for the count.

So the solution to this was run a database query that grabbed all the issues and the number of non-closed subtasks they had. Then programmatically take this number and add one to it (for the issue itself) and generate a comma separated text file, with the project, issue key, summary, and Total Issue Count. From there, a quick CSV import fixed all current issues.

Here is a list of the rules we created and a couple examples for illustration:

Automation Rules List


Rule 1 - Create Non Sub-task


Rule 7 - Delete Unresolved Sub-task




Greetings!  What are these "true agile methodology" and "ideology" of which you write?

Like robert.nadon likes this


Log in or Sign up to comment

Atlassian Community Events