Remaining values in Agile burndown chart does not match time estimates for issues with subtasks

We are new JIRA users and we launched our first sprint. For this sprint, we are using the following estimation configuration,

Estimation Statistic: Original Time Estimate

Time Tracking: Remaining Estimate and Time Spent

At the start of the sprint, we made time estimates for all the issues. Then we started adding subtasks to many of the issues and made time estimates for the subtasks. We noticed that the remaining values for our issues with subtasks includes both the overall issue estimate AND the estimate for each subtask. For issues with subtasks, the remaining values in the burndown chart are now double what they should be. We tried changing the estimate for the overall issue to 0 so that only the estimates for subtasks are counted in remaining values in the burndown chart but that made a mess of time accounting in the burndown chart.

With the estimation configuration we are using, how do we make estimates for issues with subtasks so that the remaining values are accurate in the burndown chart (e.g. no double counting of estimates).

More importantly, can someone recommend a best practice for estimating time for issues with subtasks to maintain a high integrity burndown chart.

Our burndown chart is a mess for our first sprint. We want to make certain that we set up our sprint correctly the next time so that our burndown chart reflects the reality of our work and progress.

1 answer

I performed some experiments and came to the following conclusions when making time estimates for issues with subtasks:

  • Case 1: An issue is organized as a collection of subtasks with all work performed in the subtasks. All time estimates are performed in subtasks, and the time estimate for the parent issue is 0, since no work is performed at the issue level. This avoids double-counting the work at subtask level and parent issue level.
  • Case 2: An issue is created with an initial time estimate. During the sprint, the assigned developer realizes that he forgot to include time for documentation and some testing. He therefore adds two subtasks to the parent issue for documentation work and testing work and estimates the time required to complete both. Since the subtask work is being added to the original estimate of the work performed in the parent issue, all is well. JIRA automatically sums the time estimate from parent issue with the estimated time for both tasks to cover all the work performed in this issue.

It is important to realize that these two cases must be handled differently to avoid a burn-down chart with inflated time estimates.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Feb 26, 2019 in Jira Software

How to prevent the propagation of unused project schemes, workflows & screens in Jira software

Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...

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