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.

3 answers

This widget could not be displayed.

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/

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

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.

This widget could not be displayed.

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

@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.

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.

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

This widget could not be displayed.

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

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)

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Published Apr 22, 2018 in Jira Software

How-to setup a secured Jira Software 7.9.0 on Ubuntu 16.04.4 in less than 30 minutes

...PermissionsStartOnly=true User=www-data Group=www-data ExecStart=/opt/jira/bin/startup.sh ExecStop=/opt/jira/bin/shutdown.sh TimeoutStartSec=120 TimeoutStopSec=600 PrivateTmp=true [Install] WantedBy...

1,082 views 6 12
Read article

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