This is indeed something that would really help us to see if we are on track to finish all of the work in a sprint.

Our stories are graded in Story points obviously but to encourage teamwork we create subtasks and put some hours on it. Team members use the swarming technique to finish the story so they pick up subtasks and log their work on these. This is not reflected in the burn-down so only after the complete story is done (after a couple of days) we know if we are on track or not...

This functionality is available on Jira Server so no idea why this was removed

I'm just starting to use Jira Cloud and I have a general feeling of putting a great step back...

I clearly understand why everyone is looking for this functionality. Sometime I also wish for this functionality. however, if we think in true agile/scrum spirit, we estimate user stories. we add sub-tasks to make it more granular, but they are very dependent of the story

We estimate stories using story points ( i understand there are many teams estimating in hours/days etc as well)

if we estimate sub tasks in story points, what is the point of estimating the story in the first place? if we need an ability to estimate sub tasks in story points, then the main story should not be estimated. having both is definitely going to make lot of confusion 

One of the creator of Scrum Jeff Sutherland himself stated that Estimating tasks will slow you down, don't do it. He also stated that best teams have small sorties and do no tasking. 
so split the stories into small chunks.

I can see the harsh reposes coming to this but hey, that is how scrum works.

Yes, we would very much like this ability. It would give us a much more realistic idea of how we are progressing towards Epic completion

This is absolutely required.

Estimating subtasks for a story is essential for many.  We work on one element (subtask) of the 'big picture' at a time (parent task/story).  Time spent is tracked.

When I'm asked for a 'date' for when I will deliver something 'story points' will not help me.  Time estimations will.

I don't know why anyone would come here and discuss not wanting an option like this. If you don't like it don't use it. It would be incredibly helpful for our workflow.

I see sub tasks not considered on burn down chart as a good thing. Estimation should be at the story/task level and not at sub task level. Sub-task is to describe the steps to deliver the value and there is option to record the time 

This would give a much more realistic view

Yes, I would like that feature too. 

This issue has been around for ages and seems to have been forgotten by the Jira business owner. Our team has moved on to other metric tools to follow sprint progress and estimation.

I recently took the Jira subscription and currently evaluating the product. I found this issue with the burn down chart few days before and logged similar ticket with Jira support. Looks like there is no resolution for this.

I vote for fixing this issue otherwise scrum teams can not visualize their sprint progress.

If Atlassian does not address this issue, I will be forced to look at other platforms in 2019 - end of story. This ask is important and I believe trivial to get completed.

Hi,

It seems to me that his issue has been around for years. If Atlassian does not want to deal with it then please indicate this clearly instead of continuing to provide false hopes on the part of your user base.

Sincerely,

Georges Dagenais

Hello,

I experience the same issue. Without the option that the estimated time of sub-tasks is considered, only of the parent-issue, the burndown-/burnup-chart is useless.

Actually the burndown-chart and also the burnup-chart fit all the requirements I have, only this issue with not including sub-tasks makes it useless somehow.

Please adress this issue soon.

Kind regards,

Dennis Lettner

I have to join Erl Egestad.

This is an issue that concerns ALL reports. I've got the same problem with Version report and Release-burn-down.

In the reports should be an option, to decide whether you want to include time estimates of sub-tasks or not.

When you open a story with sub-tasks on the board, there's also the option to include time-estimates of sub-tasks for the time eastimate of the whole story.

I don't understand where's the logic to not have the same option for reports.

Jira should decide how they deal with sub-tasks, but then there should be a consistent dealing with sub-tasks.

When using time estimates on sub-tasks, the estimates will automatically be added to the story estimate. That's the reason why we reduce time estimates of stories.

Due to that not including all time estimates on Jira Board and reports doesn't make any sense to me.

Please address this. And soon. Not having this option leaves basic agile reporting worthless. I don't understand how this issue has been around for this long and nothing has been done to address this.

We wish to track hours remaining on sub-tasks, so that we have a relatively granular view of progress burn down during the sprint.

As I reported in GHS-12619 I have trouble moving subtasks out of a sprint. Quite often we start a sprint with stories containing subtasks that might be postponed, eg. a documentation subtask or a GUI update that might wait. So we choose to deliver the story for sprint review, but wishes to move the documentation or minor issues to a story in a later sprint. Moving the subtasks out causes the estimation on these subtasks to remain in the burndown.

To make this work I have to set the remaining estimate on the subtask to 0h first (updating the story remaining time automatically), move the subtask to another parent story issue and then set the estimate on the subtask again after the move.
If we forget this we get a burndown that never reaches the floor.

Having the same issue but with time tracking and hours estimation at the Sub-Task level. So, we'd like to see it addressed for that also - not just story point estimation on Sub-tasks.

Not sure if it helps you guys, but we've just released the first version of our hierarchical view/editor (Epics/Stories/Sub-tasks) plugin for JIRA Agile, and beside many other features it can make your Story estimates equal to the sub-task estimates, also it calculates Epic estimations as well.

You can try it here http://demo.plangle.io (just select a board and click on the "Plangle" button next to the Plan/Work/Report trio).
And of course you can download it from the Marketplace https://marketplace.atlassian.com/plugins/com.moresimp.plangle as well.

We are in the early stages of the development with a bunch of features in the queue and we are open to any suggestions, just let us know how we can help your processes so that we can include your ideas in the upcoming releases.

We really need this to be fixed! Any updates?

Linked 7719, 5614, and 5212. All related to the handling of sub-task estimates, I think.

Is this being fixed? It's on of the most widely reported problems by our users

How can such basic and important functionality be considered trivial. Has Atlassian completely lost it? This essentially renders entire agile plugin useless for us.

Would love to see this fixed as well. The current implementation renders burndown charts and sprint health useless for all projects I've been involved in so far, you get a few cliffdrops instead of a steady burning of points. Any solution where parts of the story points are burned when completing a subtasks, that doesn't add manual steps for the team/SM, would greatly increase the usability imo

Agreed, a big headache. To help get more accurate progress tracking on the Version (ie. burnup) chart when using sub-tasks, I have been distributing the story points across the sub-tasks, so that I get burnup as the sub-tasks are completed. Initially I work with the team to define story points for each story. Then, when a story is allocated to a sprint I add the sub-tasks to the story, spread the story points across the sub-tasks, and zero out the story points on the Story (so that you don't get double story point counts on the charts). This approach helps gauge team progress during the sprint and the bosses seem to be satisfied with the resulting Version/Burnup chart. The downside is that you loose the original story point numbers on the stories. You can look at the sub-tasks for that, but then you have to open each sub-task issue which is cumbersome, so I usually capture the original story point number in the Story's description field for easy reference.

For the Sprint and Burndown Charts in Greenhopper to be meaningful I make sure each sub-task has an Original Estimate of time defined before the sprint starts, then during the sprint I diligently log work (eg. hours) each day as the team progresses toward completing tasks and stories. It's a lot of work but helpful to gauge team progress and the daily round of logging work helps keep the team focused on maximizing their velocity.

We are doing exactly that @bill langton, Epics - Stories - Subs in order to get the progress data on issue level to work. But it is not optimal solution, a lot of issue handling overhead.

I have not seen any plugin that can help us with this.

Trivial?

Because we cannot get realistic/accurate progress reporting from JIRA Agile Story/Subtask groupings, we are discussing the use of Epics in place of stories, and tasks in place of sub-tasks. This introduces other difficulties which I'm not happy about but at least it is possible to get accurate progress data.

JIRA Agile doesn't seem inclined to do anything to resolve this problem, Are there any plugins out there that are viable replacements for JIRA Agile?
I would consider going back to a self-hosted Atlassian if an alternative exists.

I definitely don't agree that this is trivial.

To usefully track burndown, the chart by story is not enough. It typically stays flat throughout the sprint with the occasional cliff drop. Whilst this is useful for tracking progress of closing stories, it doesn't tell us anything about overall progress and how close we are to closing stories. We really need the burndown by task as well as the burndown by story.

Until this feature is added, there is too much guess work involved.

Agree with Stig. Please make this configurable and let USERS make the decision.

Tempo users: Are there any reports in Tempo that will provide an accurate summary view of the total estimated work for an Epic (i.e. including subtasks)?

Same here - we complained about it one year ago. Nothing happened! Added a switch to toggle sub-tasks into the calculation for the burndown please.

Same problem here!
I can't use the burndown chart because it doesn't reflect the reality during the sprint (only in the end), as I have main stories with 150 pts and a lot of sub-tasks. Unfortunately I can't use Shaun's suggestion because I already use the hour estimation for another process in my team.
This fix would be extremely necessary for me, someone else has any other idea?

sclowes this workaround is a joke because in addition to story points we actually do track time spent on each issue using Tempo plugin to generate time sheet.

To mitigate this, we currently break down story points in parent description field for each subtask and write total on the parent. Please fix this right now.

We are having the same problem here. To much of our work is done in a manner where the main story is finished later in the sprint. The effect on this is that the burndown starts to reflect reality in the mid-end of the sprint.

I don't think Atlassian's view should be forced on the users in this way. Adding a simple yes/no configuration setting to allow sub issues to be treated as any other issue would make a lot of people happy.

Under the Time Tracking option, we are using "Remaining Estimate and Time Spent". Maybe I misunderstood this issue. I did some testing and created a new issue (GHS-7704)

Hi byoung,

It sounds like your situation is completely supported, enable 'Time Tracking' in the estimation configuration for the board and the burndown will then burn the hour remaining estiamates ont he issues.

Cheers,
Shaun

This has rendered the burndown charts fairly useless to us. We estimate Stories in points and then create subtasks in the iteration. The subtasks get estimated in hours. I imagine this would be a pretty common practice.

We could burn down by stories, but that wouldn't be granular enough to be useful. Until stories started finishing, the burndown would be relying on hours logged rather than tasks completed, which would put too much emphasis on the estimates.

Unfortunately this is only supported with time based statistics by enabling 'Time Tracking' in the estimation configuration for the board. You might like to try using Time Tracking but having 1 hour = 1 point, this will achieve what you're looking for.

Thanks,
Shaun

Would love to see this fixed; we estimate sub-tasks instead of rolling up the points to the top level ticket.