nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

TaskBurndown_vs_StorypointsBurndown.jpg

Accepted answers

All comments

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 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?

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.

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

Senthilkumar Ananthakrishnan

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.

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

(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)

Balaji Ashwathaiah

Just

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

Ivan Grimaldi

Thanks! This reply helps us a lot!

Aleksandr Makarov_xqr5i1

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

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.

Pablo Silva_y68wxj

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

sprint

burndown