This issue says "Resolution: Tracked Elsewhere" ...

I wonder were "Elsewhere" might be. Maybe JSW-9167?

So sad.

Aha, Atlassian thinks this request is no Blocker (any more) ... well not having e.g. GHS-3922 blocks 2000 users at www.softwareag.com from using the new boards.

Thanks for following this issue. This story covers a number of feature requests for JIRA Agile via issue links.

Since this issue was raised many of the requests have been delivered including the following from the issue links:

• GHS-6128 Non-working day support in the Sprint Burndown chart and gadget
• GHS-5118 Non-working day support in the Control chart
• GHS-6467 Sprint Burndown gadget
• GHS-6466 Days Remaining in Sprint gadget
• GHS-5113 Project Progress gadget
• GHS-6828 As a Classic user I would like my epic labels migrated for use on the new boards

Remaining issues which are in progress or will be worked on soon include:

• GHS-3922 As a user, I would like to configure the cards displayed in the rapid board
• GHS-6131 As a user, I would like to be able to re-organize pre-sprints in planning mode

In order for us to track the remaining requests and understand the demand for each of them please vote or comment on the individual issues. I have now resolved this issue as tracked elsewhere.

If your requirements are not covered by the above, or in an existing story in this project, please add a comment below. Your feedback on these issues is welcomed.

Kind regards,
Martin Jopson
JIRA Agile

Being able to see epic-based statistics on the dashboard is kind of a big deal for us. We have a lot of project owners and other roles who don't need to go into the Agile board but need to know information broken down by epic.

Pro Tip: The more issues you link to this request, the more votes you get!

My request is currently rank 5 of the most voted GreenHopper requests (see attached screenshot)

Yes, that's true. Even though >support< really tries to help and does a good job, Product Management on Greenhopper has burdened themselves with developing an additional completely new solution while the current solution (classic) that most enterprise customers use (and pay) is completely stalled on new features. The new Greenhopper is mostly still unusable for enterprise customers as it lacks most of the features that enterprises need (see above). We are paying thousands of Euros each year for getting nothing back. Every new team that started with the new greenhopper finally disappointedly went back to the classic board because they are lacking release planning and Wallboards and other important features. My team even reintroduced a real wallboard with index cards because it is much better suited than the tool (thanks to the new Greenhopper!

My company is currently thinking about one tool for the enterprise and Atlassian >was< on the list for years...What Atlassian doesn't take into account: If we drop their product, hundreds of our clients will do too and we won't recommend it anymore.

We will have a meeting with the new Greenhopper Product Manager in a week and I hope we can convince Atlassian to change their strategy. They are big and wealthy enough as a company to finally understand what is really important and really invest on their used-to-be flagship instead of throwing many other products onto the market.

What's most disappointing to me is that some of this (the dashboard gadgets) was committed to being done to the attendees of the first Atlassian Enterprise Training last October and is still not done. What it boils down to is this. Slapping "Enterprise" on it does not make it Enterprise. Satisfying Enterprise needs may mean increased cost (account managers, more developers, etc.) and if that's the case, so be it - most enterprises are willing to pay a little more to get functionality they need. What they're not willing to do is wait around for changes that were committed to and then missed.

Dear Shawn,

> Complexity of the user interface due to configuration options is the most common complaint we receive from customers

You did not hear from us because we were totally satisfied with the configurability of the classic boards...

Thanks for your understanding.

What i´m really missing is to set version and component hierarchies in the agile board or, even better, on the project admin page itself. I mean, the place where i create and release versions should also be the place to set version hierachy, shouldn´t it?
As example we´re releasing one stable release end of each week on TEST and there is a strict version naming convention: Live-Release-No.Sprint-No.Week-No. -> 0.9.2 means it was not released on live yet, belongs to sprint 9 and it´s the second sprint week.
But as all these 0.9.something belong to sprint 9 i would like to get them automatically to version 0.9 which was possible in the classic boards.
Reading the stuff above i couldn´t find any updates regarding the hierachies, so what about them?