I've had a long thread of discussion about this with the support. At the end I was directed to post my findings here.

When doing a planning, we estimating and assigning tasks to people. The option to see a list of people with how much time they have planned for the following sprint is very useful, but it fails if you have story with sub-tasks because sub-tasks are not taken into consideration.
Now, if I would to manually input the estimation into the story then I would see that issue and it's time estimation for the user that it is assigned to, but if I select the option for story to collect it's sub-tasks estimations, the collective estimation does get shown in the story issue, but then it doesn't work.
To me this is a simple behavior which should work, but it doesn't. It's not a desired behavior which goes against the Jira software behavior, it's just a simple bug - is the value considered, or not.

From the user perspective it looks like a simple bug: the value being used when defined on the story itself is okay, but the value being generated from sub-tasks is not.
So, from the user's perspective it sounds simple, to just include the value being generated as it is right now with the manual input.

This bug makes the "Include Sub-tasks" in Time tracking useless, and it is a really nice, and a very much needed feature.

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.

Regarding the fact that the Estimate shown in the sprint marker includes only the estimates on primary backlog items, this is deliberate because when looking further forward in time it's unlikely future items will be broken down in to tasks

There's an easy way to tell whether or not the item has been broken down into subtasks: the item has subtasks! If the subtasks exist, and have estimates, they should be rolled up!! Or, as many people have commented, it should at least be an option to do that.

We've solved this: during the sprint, the team updates Story Points field on parent issue by asking "how much points are their remaining?" resulting in points reduction or increase. This makes the chart burn down though the issue is still in progress

We recently upgraded from Jira 4.4 to 5.1.6/Greenhopper 6.0.4, and this has been the biggest problem that we have run into thus far. Without point rollup from subtasks, the new planning board is mostly useless to us. Our workflow may not match your blueprint for Agile, but it is what we have found works well for us. We're open to learning new things, but this functionality is core to our workflow as it exists today.

Our current process:

1. Identify Epics and Stories
2. Prioritize stories in backlog
3. Discuss stories and provide rough estimates
4. Plan release around top priority stories & necessary backlog items (bugs, small customer requests, etc)
5. Break down stories into subtasks, estimating each individually
6. Clear out initial estimate
7. Distribute issues into sprints

Observations from the discussion above:

1. Please refine/focus this issue on how GH handles Story Points - Hours/Original Estimate rollup appears to be handled in GHS-5283
2. We found mixing points with hours really confused things and caused us to create too much of a correlation between points and time.
3. We treat story points as a measure of effort (not as a measure of customer value as some others have indicated)
4. We prefer to burn-down on subtasks, not stories
   1. Note: You could argue that our stories are too big in this case, or that we don't plan well, but this is what works for us. We may implement the DB and Logic in Sprint #1 (with tests), and then the UI in Sprint #2. We don't credit the story till all subtasks are complete, but we do want to burn down the points in the sprint - ie: get credit for the work.
5. Perhaps creating an "original estimate" like field for points would be valuable (at least for us)

... off to figure out a temporary solution using the API until this gets resolved.

Already did, but it didn't change it. I even restarted the server.

Emmanuel

emmanuelpotvin: This is controlled by the Time Tracking settings in JIRA, check out the documentation on configuring time tracking.

Thanks,
Shaun

Is it possible to show time on hours only? (17h instead of 2d 3h)

Hi robjansen,

Check out the screenshot in the release notes. 6.0.3 should roll in to OnDemand in the next week or two.

As before, we don't recommend the use of remaining estimate for sprint committment.

Thanks,
Shaun

Hi Shaun,

What do you mean by the Sprint footer? Where can I find it?