Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

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.

6 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

@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 # people like 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 # people like 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

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.

Like # people like this

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.

Like # people like this

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.  

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

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

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.

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase

The benefits of using Jira in different departments

Jira is a great tool to use across different departments. Forget that paperwork – switch to Jira and get that tasks done smoothly. Marketing Jira allows for a complete digital transformation of you...

110 views 0 7
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