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

[vaar]

The Burndown Chart Shows Story Points vs. time.

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

[Dirk_Maucher]

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.

http://blog.novatec-gmbh.de/how-to-add-the-missing-sub-task-burndown-chart-to-jira-software/

[Christian Dähn]

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,
Chris

[Sandy]

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.

[Pablo Silva]

I used that approach in the past, and ir really works fine, if that is OK for the team.

From memory, I had a Sum Remaining on the parent US/Task that would sum remaining time for every sub-tasks, and then burndown would be based on this value. That really gave a clear view of the progress on burndown, alerting us about if there was a major deviation or if we're able to add scope to Sprint.

Team did not considered this estimation to be a great effort, as there was not a great precision required.  

[Rahul Aich [Nagra]]

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

[vaar]

@Rahul Aich [Nagra] - thanks for the reply

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?

[Rahul Aich [Nagra]]

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

[Brian Cody]

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.

[Josh Woodcock]

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.

[Christian Peper]

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.

[Reg Hawkins]

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

[chris]

It seems that nearly 6 years on, the only option is to pay yet more money on top of significant amounts of money we spend to use Jira  to get what really should be core functionality by buying ridiculously expensive plugin gadgets from 3rd party suppliers.

[dranix1024]

Completely agree

[Balaji Ashwathaiah]

Just

1. make sure your filter query in the Board also includes 'sub-tasks'
2. Enabled time tracking
3. Configured estimation and tracking: https://confluence.atlassian.com/jirasoftwarecloud/configuring-estimation-and-tracking-764478030.html
4. all your sub-tasks are added before sprint start date, time

[Ivan Grimaldi]

Thanks! This reply helps us a lot!

[Danut M _StonikByte_]

Hi @vaar ,

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.

[Aleksandr Makarov]

Hi

Maybe this would help:

https://community.atlassian.com/t5/Jira-questions/Configure-Sprint-Burndown-Chart-to-show-number-of-open-Sub-tasks/qaq-p/1124137#M361720

[Kelly Arrey]

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 https://jira.atlassian.com/browse/JSWSERVER-16241 if you'd like to see the option for a custom field added to the Sprint Burndown gadget.
Thanks !
Kel

[Kelly Arrey]

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 com.atlassian.jira.security.JiraAuthenticationContext
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
    parentIssue.setCustomFieldValue(cf,newValue)
    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)