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. We believe that this feature request is a band aid solution to those missing features. We believe that this feature would take time and energy away from us making the new boards even better.

While we understand the desire for this feature it 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 this option adds to the ongoing cost of testing and maintenance, which hiders the teams velocity over the long term.

As we continue work on delivering many new features in GreenHopper 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.

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!

Thanks for your patience, and we hope you appreciate our open approach to feature requests and backlog ordering.

Cheers,
Shaun Clowes
GreenHopper Product Manager

Question: "our most recent user survey" ... what does that refer to?

Hi rainer mueck, shoehn2,

Thanks for your continued feedback, please know that the GreenHopper team are working extremely hard to deliver a great product.

On the voting front, I think we have discussed this already in GHS-3922, but I'm happy to cover it again.

Votes do matter, we look at them regularly and do consider them when prioritizing features. However, Votes just aren't simply a trump card, and we don't simply translate votes directly into priority. We listen to the voice of our customers in many ways other than just votes:

• Customer contact: We get the chance to meet customers and hear their successes and challenges at Atlassian Summit, Atlassian Unite, developer conferences, and road shows.
• Customer interviews: All product managers at Atlassian do customer interviews. Our interviews are not simply to capture a list of features, but to understand our customers' goals and plans.
• Community forums: There are large volumes of posts on answers, of votes and comments on JIRA.atlassian.com, and of conversations on community forums like JIRA groups on LinkedIn.
• Customer Support: Our support team provides clear insights into the issues that are challenging for customers, and which are generating the most calls to support
• Atlassian Experts: Our Experts provide insights into real-world customer deployments, especially for customers at scale.
• Evaluator Feedback: When someone new tries JIRA, we want to know what they liked and disliked.
• In product feedback: The 'Got Feedback' lin that we embed in the product give us a constant pulse on how users are experiencing our product.
• Usage data: Are customers using the features we have developed?

The amount of feedback is massive, especially when you have over 8,000 customers, and hundreds of people trying your product every day.

The key message here is that votes are not the only item of data we consider when implementing a feature. And the users that contribute to jira.atlassian.com are just one audience in our thousands of customers.

Looking specifically at Epics, because we use jira.atlassian.com as our own development tracking system we often create a separate issue for a story as we intend to implement it. GHS-5232 is an Epic we are using to hold our Epic implementation story. If you were looking for the source stories for Epics you'd be looking for GHS-2136, GHS-139, GHS-2150 and others. Together these issues have more votes than any other issue, but even if they didn't in our most recent user survey Epics were the mostly highly rated request and all of our other forms of feedback have continuously reiterated the need for improved Epic support.

Of course, the other side to it is that sometimes even if an issue is highly voted we can't do it because it would negatively impact our ability to deliver other things we need to do. That's the case with GHS-3922. As I've commented in that ticket we cannot make the cards configurable without negatively impacting our ability to change the UI, the configurability of the cards is a significant factor in our inability to move the classic boards forward or make any kinds of UI updates. We have discussed making the view of issues in plan mode a table with configurable columns (like the issue navigator) rather than cards, but that's not something we're considering soon.

We do listen to your feedback though, for instance we intend to cover non working days in the burndown chart and gadgets in the near future.

Thanks,
Shaun

Can you please let people vote before closing the ticket?

Thanks for your cooperative understanding and support.

I can also second Rainer's thoughts: How can a ticket that has 18 votes and is minor be more important than a ticket being major and having 217 votes and then the latter not be implemented?

I would be happy if you answered that question. Thanks you.
Stefan

Hi Shaun and Nicholas,

in a comment above I read "Epics are easily the most requested feature for GreenHopper".

Looking at GHS-5232 (Epic Support) I see Shaun as reporter, only 18 votes and priority "Minor".

On the other hand e.g. GHS-3922 (As a user, I would like to configure the cards displayed in the rapid board) has 217 votes, and priority "Major". Plus your statement "we do not currently plan to allow customisation of the card" ... plus many, many customers expressing their disappreciation.

I can't think of any explanation why you act this way. Can you understand that it looks to me like you are completely disregarding your customers needs?

with best regards

Rainer Mueck

Friends, please click on VOTE! thanks!

Added 23/Nov/12: I see, voting is not possible any more as the request has been rejected by Atlassian. Interesting way to close out potential voters ...

Mark, you are man of my own heart. Thanks for your "enterprise" support!

cheers
Stefan

Added related issue GHS-6677 (As a JIRA system admin I want to decide, if the GreenHopper UI supports "Simplified Workflows" or not)

Hi Mark,

many thanks for these wise words and your kind support!!!

Rainer

We also provided feedback at the last summit that for "enterprise" level support, more functions need to be optional, allowing for teams to opt in to features when they meet individual customer requirements, and not before.

There seems to be a sense that "you don't have to upgrade" - but that isn't true either, because new features and bug fixes that we want, are tied in with new features that we're not ready to deal with yet, giving a "take it all or leave it all".

There seems to be a sense that "you can control the people". This is completely true for teams of 10. Not so much for teams of 100+. People cannot be all be individually certified and monitored on larger scales. We need controls to lock them out of functionality which we are not ready to support, or that does not integrate with processes.

I can understand the dilemma. You only have so many resources, and you have different customers with competing requirements. You want to deliver the best solution possible with what you have. However, even with the dilemma understood and accepted as requiring a compromise - it does seem the compromise has leaned towards whizz-bang features that never really existed in the first place, over cleaning house. Gadget support missing? Unable to configure working days? There is reason for customers to be concerned here. It is a matter of trust.

Boards aren't really ready to meet existing requirements of existing users, but they were activated as the default. Users even get a warning saying "Please note there will be no further development for the classic boards" (or words to that effect). We've been working with our customers to get them to switch from classic to boards, and they've been stumbling upon the gaps.

In our case - we understood from the start that the "legacy" capability for GreenHopper to supports Epic was poor, and so we'll actually accept the new Epic enabled out of the gate as soon as it is out of labs. Whether it meets our requirements or not, it's surely better than what exists today in the classic interface. We don't need support for epics to be optional. I just wanted to give some additional support for Stefan and Rainer's position, that something is broken around how GreenHopper features are prioritized and delivered, and it is a point of concern for us so much that we also raised a concern at the last summit. (Our concern wasn't just limited to GreenHopper - but GreenHopper was a really good reccent example)

I think what is broken is an understanding of "enterprise" requirements. Atlassian does excellent in the area of supporting small teams. Atlassian is a lot more spotty when it comes to understanding what big companies need, and not only delivering features that scale well, but also delivering features with migration paths and the option to not deploy a feature which either fails to meet requirements for the customer (yet?), or conflicts with requirements from a customer.

That all said - if we accept that GreenHopper delivery of rapid boards to existing customers has been problematic - and move on from here. If you could just fix those misses around porting existing functionality that we take for granted in "classic", and deliver them in "boards", I think there is a lot of goodwill that would happily forgive and forget.