Issue estimates not correct in scrum board planning mode (not reflecting sub-tasks)

eWhen planning a sprint via a scrum board in planning mode, the time estimates on sub-tasks are not reflected in their parent issues, OR in the "workload by assignee" panel. This causes a lot of unnecessary additional overhead.

When planning a sprint, we like to sketch out about a dozen top-level stories. We then create sub-tasks under those stories, which inherit things like the epic & sprint from their parent. Typically, we only assign estimates to sub-tasks.

This allows us to create stories that involve multiple participants, and it allows us to have a quick, high-level understanding of what's contained in a sprint and how everything relates to each other... after all, when there are (conceptually) less than a dozen things going on, it's easy to wrap your head around them.

That is the critical constraint: a story may have sub-tasks assigned to different people. For example, we might have a story with sub-tasks like so:

• Revise internal API Foo (Story)
  • Plan API change (Bob, 8h)
  • API review & refinement meeting (Bob, 4h)
  • API review & refinement meeting (Sheila, 4h)
  • API review & refinement meeting (Sam, 4h)
  • Update API implementation Bar (Sheila, 16h)
  • Update client libraries (Sam, 12h)

There is absolutely no way that a top-level estimate on that story is meaningful on its own. It can be useful as a measure of person-hours, but only if that estimate is directly derived from the issue's sub-tasks, and only if the estimates are correctly reflected in each assignee's workload.

We've tried totaling up the hours in the sub-tasks and just hacking them into the top-level issues during planning, but that's terrible: it's a total hassle, and it doesn't work for multiple assignees without reorganizing our issues in totally distorted ways to accommodate the tool rather than our team.

The best solution we've found so far is to put together a dashboard with Workload Pie gadgets. That's sort of okay, but it requires us to continually switch away from the scrum board during our planning meetings, so it's still sub-optimal.

I don't know if this behavior is a design decision or simply a bug, but it's causing us a lot of headache. Please fix it. Thanks!