While server is being discontinued, Data Center will still be supported. You will still be able to run a single node Jira instance with a DC license which is essentially like running Server.

Use other plugins for reporting if you want to include sub-tasks in burndown. Alternatively, elevate your issue hierarchy. It sounds like your stories are too big if you're pointing sub-tasks.

FYI I would assume they will never fix this seeing that Jira server is being discontinued. I do have a problem with this. I suggest people start looking at hansoft as an alternative, it's much better.

Still no news on this?

Is there any update on the same ?

Yes, we are interested in this too. Another 9 years, maybe?

9 years later..... still not being considered? I just want to chime in that this is crucial as we want to break down a user story within a sprint to a more granular level to what needs to be done for that US. Example sub tasks for a US: create database, create table, populate table, create triggers, update code, unit test, progression testing, regression testing, etc.

Each sub tasks would then have hours estimate which are rolled up nicely into the user story. I don't want to have one estimate at the user story level only as that is way too broad. Now, if we have estimates in the sub-tasks, then we estimate in parent user story itself... Jira would show double!!!!

So, just to re-iterate, THIS IS CRUCIAL TO HAVE! Please make it happen. Thanks.

So does this mean that when we should ONLY be estimating and logging time to the story level? 

I am working with a team doing one week sprints. Sizing stories to be smaller than two or three days is not always easy to do upfront, so story burndown does not help much. The developers on the team are already in the habit of creating subtasks that approximate one day of effort as they pick up a story and closing subtasks as they work. It would be so very nice to be able to reflect this in a burndown that accounts for subtask completion. I don't really understand the hesitation to implement this. It has been a topic for a number of years and the Jira team takes the stance that it is not the way of Scrum. .. Subtasks are not actually the way of Scrum either, but they do exist in Jira. If Jira is going to have epic and story burndown, why not have task burndown for a sprint as well.

Indeed this is of high importance when you need to track the parent with large story points and not being able to complete with a sprint however the loss of estimate on its sub-task is not really displayed on the sprint burndown chart - that doesn't actually indicate the team velocity properly... Please consider to fix this bug..  Thanks!!

Our team also want this feature. We want sub-task issues to be charted on Burndown graph.

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.