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)

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?

I too am fairly happy with the results here with one significant concern. Not fixing GHS-6677 is ok assuming that both GHS-6892 and GHS-6893 are implemented.

I would also like to see badges added, in place of GHS-3922. One of these days I will create a mock-up and file a ticket for this.

Can we assume GHS-3873 (As a new Rapid Board User, I would like to CFD to skip weekends) as a breakout story of 5117 is in category 1? I couldn't see mention of it.

Fully agree with the grouping and the issues that are not implemented.
Are the groups ranked, or can we expect these issues to be implemented based on the number of votes on them?

Hi Everyone,

Thanks so much for your votes and comments on this feature request.

We know there are features missing from the new Scrum and Kanban boards, features that exist in the Classic boards. We do plan to implement some of these features.

• Some of these we plan to deliver within the next 12 months
• Some of these we still want to implement, but we may not deliver in the next 12 months

Just like any Agile team we have ordered the backlog based upon what we believe provides the greatest value to our customers. There are now over 10,000 customers worldwide so we try to find the right balance between the varied needs of this large, and growing, group. It is not an easy task. Thankfully we have many passionate customers that are able to provide feedback to help drive our vision and order the backlog - thank you!

Some of the feature requests listed on this issue block or hide the new boards from users, or disable new features entirely. For customers requesting these features we recommend that you begin exploring a manual migration to the new boards on your staging server today. While you undertake a manual migration to the new boards the Classic mode will remain available in new releases of GreenHopper until at least November 30, 2013 (this is the Planning, Task, Chart and Released Boards for those on GreenHopper 5.10 or earlier).

If you require assistance with a manual migration please contact an Atlassian Expert. Further, Atlassian University is available to assist with retraining users on the new GreenHopper boards.

This issue incorporates a number of features via links to 12 other issues on the GreenHopper backlog. When we, the GreenHopper team, look at the 12 issues incorporated on this issue we believe they fit in one of three groups:

1. Issues we plan to deliver in the next 12 months as they improve the experience on the new Scrum and Kanban boards
   • GHS-5117 Greenhopper non-working days are ignored in Rapid Views
     • GHS-6128 Burndown chart
     • GHS-5118 Control chart
   • GHS-5345 Add GreenHopper gadgets to the dashboard that tie to the Rapid Board
     • GHS-6467 Burndown
     • GHS-6466 Days Remaining in Sprint
     • GHS-5113 Project Progress
   • GHS-6828 As a Classic user I would like my epic labels migrated for use on the new boards
   • GHS-6020 As a scrum planner I would like the ability to reorder sprints
   • GHS-3474 As a Rapid Board user I would like to configure the detail view for an issue
     • We have already delivered a variety of field types in a release by release fashion including dates (GHS-5831), resolution/environment/security (GHS-5833), business value/numeric (GHS-5832), text (GHS-5735)
     • We have two stories left to deliver: User/groups (GHS-5835) and label/select/check/radio/version (GHS-5834)
2. Issues we may deliver in the future
   • GHS-3681 As a Rapid Board owner I would like the ability to have cell (column and swimlane) min/max constraints
     • Note, it is possible to add column constraints on the Scrum and Kanban board today. This story covers column and swimlane (row) constraints.
   • GHS-6790 As a Scrum Master I would like to use a predefined template for my Rapid Board
   • GHS-3922 As a user, I would like to configure the cards displayed in the rapid board
     • This request is very wide in scope, we are continuing to investigate the various use cases and may provide functionality to address the major needs in the next 12 months
3. Issues we do not plan to deliver in the future
   • GHS-6677 As a JIRA system admin I want to decide, if the GreenHopper UI supports "Simplified Workflows" or not
   • GHS-6753 As a JIRA system admin I want to decide, if my users see GreenHopper Classic, RapidBoard or both in the JIRA UI
   • GHS-6789 Please remove message "The Classic boards are no longer being actively improved ..."
   • GHS-6626 As a JIRA system admin I want to decide, if the GreenHopper UI supports Epics or not

While we understand the desire for the features under 3) these options will add complexity to the product and hinder adoption by new teams. Complexity of the user interface due to configuration options is the most common complaint we receive from customers, and our continued goal is to make GreenHopper easier for teams to adopt. Further, adding these options adds to the ongoing cost of testing and maintenance, which hiders the team's velocity over the long term.

As we continue work on delivering the features under 1) there are a few options open to you. You can start switching individual teams over to the new boards as they complete their current sprint, project or release. Alternatively, you can continue to use the Planning, Task, Chart and Released Boards and the current functionality by remaining on GreenHopper 5.10.6 and JIRA 5.1.2 , or by using the 'Classic...' option under the Agile menu in GreenHopper 6.0 or later.

If you are not watching the individual issues that you are interested in, please do so to be notified when they are delivered. Also, please comment on the specific issue you are interested in (ie, not this issue) so that we can easily determine which comments and votes relate to which feature.

Thanks for your patience, our open approach to feature requests and backlog ordering allows us to share our work with you and we plan to continue delivering great new features over the next year.

Cheers,
Shaun Clowes
GreenHopper Product Manager

Nick Muldon essentially told us that there will be three packages: one that they will implement within the next 12 months, some that they might be able to adress within the next 12 months and some that they will completely close as "won't fix". He told us the ones in detail and Atlassian will inform the community within the next hours about their decision. Unfortunately some "won't fixes" are hard for us to understand.

I can second Rainers view that he is disappointed the way they are currently going but I like to be fair to Nick that ia able to provide the strategy to all of us. Basically Atlassian wants make their products easier to handle and take out complexity, which is why they are not willing to implement some old features that many of us used up to now.

=Stefan=

I leave it up to Atlassian to publish their plans.

rmk: "Unfortunately, for me, the worst possible case became reality." => which possibility is that? They won't do anything?

You can't say it's important for all; only for the ones that use Epics in the current situation.
That being said, you have my vote/+1.

Can you please all vote for the following ticket as this definitely is important for all that using the current classic board and want to move to the rapid board in the future: https://jira.atlassian.com/browse/GHS-6828 (As a Classic user I would like my epic labels migrated for use on the new boards)

Thanks
Stefan

I'm also a HUGE proponent of Atlassian. And as I wish that it stays like this for a long time, I drive this initiative with all my energy

Thank you all for your support!

Rainer Muck

Sara's comment against this issue is SO VERY SPOT ON ).

https://jira.atlassian.com/browse/GHS-5345?focusedCommentId=419860&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-419860

I'm battling Sr. Execs in my large org who want to know why we can't get simple dashboard functionality to support us, and I continue (weekly) to try to convince them that it is 'coming'. Status reporting w/o visuals is an extremely painful sell. And I'm a huge proponent of Atlassian.

I'm with Bill Warshaw here.

We need the Dashboard gadgets to be directly supported from the Rapid Board, not only for Wallboard displays, but also in our Confluence Pages that are visible to folks outside of engineering.

I'm kind of (not) amused at Shawn's response here - while it may not be your process, telling customers they are "doing it wrong" is not a way to keep customers. And, by not disclosing that RapidBoards do not support Wallboards, yes, you've broken functionality that we expect.

One of the main reasons I pushed my company to move to Atlassian was the ability to have a dashboard with greenhopper gadgets for all scrum projects.

After moving all projects to Atlassian Greenhopper rapidboards, it was quickly apparent that the new rapidboards do not have corresponding dashboard gadgets to use. This is the one item where we cannot find a usable workaround.

We very much vote for Atlassian/Greenhopper to move quickly on getting the dashboard gadgets integrated with rapid boards.

Luckily, we just started using GreenHopper, and immediately went to the Rapid Boards, never used the classic boards. But I agress that mnimally, Dashboards Gadgets for the Rapid boards need to exist, as for many organizations, the Dashboards, and Gadgets themselves (which in our case, are often displayed on the pertinent Confluence project status page) need to support Rapid Boards.

-Brian Cohen
QA Manager
Corero Network Security

My biggest issue at the moment is the lack of dashboard support for the Rapid Board information. Since we started using GH after the rapid board was introduced, we're generally happy with the board itself. But at a project sponsor and team level, we need to be able to provide dashboards that display not only the useful reports such as burndown but also other team type information such as project stats and such. Since we're unable to use the agile dashboard gadgets with the new rapid boards we have to go two places for this information.

Thanks for your consideration,
Kim

Hi There,
I put my vote for GH improvement. Many our user request to have follow features in new board,
1. Able to configure the card / fields display in plan mode.
2. Able to associate Non-working day in Agile chart eg. burn down chart.

Regards,
Jutamat

Hi mikeohren,

We are continuing to release every two weeks, the team is putting in every effort to deliver the features that will make you love the new boards.

You know that you and I disagree on the definition of broken, however as I noted above we do plan on addressing weekends in the burndown soon, we just can't tackle everything at once.

Thanks,
Shaun

Shaun

I have just had a renewal reminder for next year, how do you think I feel about the current maintenance where you tell me I should just stick to classic board for the functionality I want. Rapid boards are what I am paying for and the reporting functionality is broken. If I am going to stick to legacy GreenHopper features only then why should I renew?

At least pay us the respect to acknowledge this is broken, it's important to us and we have a valid concern here.

Thanks Gregory, I linked GHS-5117 (205 votes) to this issue.

Rainer, thank you for inviting others to participate, but as a large enterprise customer the only desire from the above list that we share is card customization (GHS-3922). We would consider sprint reordering (GHS-6020), flag as ready (GHS-2526) and non-working days (GHS-5117) to be higher priorities than all of the issues linked to this ticket.

As outlined by sclowes; my votes and comments are to be found on the original issues.
Most of the things you (rmk) mention are not important for us (a switch to put the classic boards above again).

My personal top 2:

GHS-3922:As a user, I would like to configure the cards displayed in the rapid board
GHS-5345: Add GreenHopper gadgets to the dashboard that tie to the Rapid Board

Apart from that; i like the work that's being put into the Epic support, only we have another 'level' with a custom label field called 'Theme'. What i would really like to have is to be able to use an hierarchy in epics.
The one that gets the closest to this is:

GHS-5667: A "helicopter view" or "vision mode" for a big picture next to sprint and task focused views (forrests and trees)

Hi All,

Please note that we can't really use feedback in this form (i.e. a list of individual issues that 'must' happen). There are a few reasons:

• The individual stories already exist, if you are interested in them then you can comment and vote on them
• Having this issue separate means that we cannot easily determine which comments relate to which feature and which votes represent a desire for which specific features
• We cannot implement a list of features, as you all know we release every two weeks, as a result we deliver incremental functionality across releases

As such we can't take this issue in to account during our planning. I'd ask that we please use the original issues when providing feedback.

mikeohren, as I've mentioned before, we have not taken away any functionality, the classic boards operate exactly as they have before. While building the new GreenHopper (which we obviously have to deliver feature by feature), we have first delivered features to meet the needs of smaller teams since we can't add enterprise functionality until we have this functionality in place. We hope to keep delivering functionality quickly and win you back over.

We are already addressing GHS-3474 ("As a Rapid Board user I would like to configure the detail view for an issue") and have been delivering additional field types every two weeks. We intend to look at Gadgets (GHS-5345) in the near future. We also intend to look at GHS-6128 (burndowns charts handling weekends) in the near future.

Thanks,
Shaun

The Card customisation must support with JIRA Issue fields as well as the any type of Custom fields.

The Size of the Card also configurable to support the display. In order to fulfil this requirement, to provide an option, that will enable for a user to hide/show selected Column’s on the fly.

These, and especially https://jira.atlassian.com/browse/GHS-5117 are important to us.

I can only echo Bernhard, someone at Atlassian is not listening to customers. It's so frustrating to find a really good product only to see it go backwards in critical functionality. Atlassian are adding a lot of really nice features in the product but have broken some big things in the process.

I can only second this and the related issues, each having more than enough use cases. Rapid Boards can be a success only when they retain (or regain) the customizability of the "classic" GreenHopper Boards. They might even surpass them in terms of flexibility and power.

Somebody within Atlassian is definitely not listening to customer demand. The points made by Atlassian in the various issues are all fine and understandable, but they don't take away a toy. They declare "Classic" Boards as deprecated while at the same time the Rapid Boards don't have the functionality of the previous solution.

I really cannot understand this behaviour unless you explicitly want to drive customers away. There are not many good alternatives, but this is - at least in my opinion - no reason to behave like this.

Absolute must-have is a configurable rapid board. Every team should be able to configure the card view as well as the detailed view.
I work with several different teams, and each of them has different workflows and values, so a hardcoded layout would only satisfy the needs of very few customers.

Each Scrum team is diffrent
Each Kanban team is diffrent

Critical information for one team may be useless for the other.
Boards should give a fast overview what's going on in the team.

All this leads to the conclusion, that the information displayed on the cards has to
be customizable to the wishes and needs of the team working with the board

We have about 200 cards on each board

It is absolutley impossible to use the details area on the right side to information which
we need in the overview.

therefore:
as an enterprise jira user and atlassian customer I support this request

best

///Sascha Ernst///
Intex EDV-Software GmbH
Germany

Stefan Kalhofer (SAP), Stefan Höhn (CSC) and myself (Software AG) will be having a phone conference with Nicholas Muldoon from Atlassian on next Thursday.

If you wish to influence a change, TAKE YOUR CHANCE NOW in supporting us.

Please express yourself with respectable comments and votes on GHS-6754 and related issues.

Many thanks in advance.

Rainer Mueck

Update:

The meeting took place on 29-Nov-2012. There are no concrete results yet, but there will be a follow-up meeting in one week. So please stay tuned for more updates to come.

Update 2 (06-Dec-2012):

The follow-up meeting today resulted in clear statements from Atlassian regarding this request and its related ones. Unfortunately, for me, the worst possible case became reality.