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

Thursday works for me as well.

Thanks for your kind invite.
Unfortunately I am giving a Scrum Training on Monday and Tuesday, which is why I have proposed a new time (thursday).

cheers
Stefan

Hi Stefan,

I have a call with Rainer and Sven on the 27th at 5pm, I have added you to the invite.

Thanks,
Nicholas

Hi Nicholas,

as stated by many other commenters on GHS-3922 and other issues, customers are screwed with the new board. No chance to migrate!

It is extremely embarrassing and unbearable that the new GreenHopper forces companies like mine to change their processes, instead of supporting the existing ones – do you really want to read that in the headlines?

looking forward to our telephone conversation ...

kind regards – Rainer

Nicholas,

really, I have to jump in here because there are several points that, from my perspective, are actually not really true:

1) It is not necessarily the issue of custom coding! Your "legacy" customers who are actually the ones to make Greenhopper famous are now the ones who are suffering. Those who made you big are now the ones you burdening with a "new" Greenhopper. Passion is about love and hate. We loved the old greenhopper (even with some of the old deficiences) and now we are going to hate it. In my case it is NOT custom coding, it is the change in the process without having a migration path (see below)

2) It is absolutely wrong stating that the old greenhopper did not support Epics. It does and I am using it a lot and I AM happy with that. It might be the case that the new implementation is better than the old but it is again only a half-way implementation. It is common sense in the agile community to have more levels. Themes-Features-Epics-Stories-Tasks. Why do you again have this artificial limitation that also Jira always had (which is one of the most wanted features never being implemented). Other competitors (TargetProcess, Rally etc) do support that.

3) "We are addressing the deficiencies of the past. We would love to have you on board, providing feedback, passion and purpose to the GreenHopper team. Please migrate to the new GreenHopper as time permits you and your 2,000 users"

Sorry to say this but only someone who is not in charge of running a system of that size in a big company as you probably are can say that. It is ridiculous. Do you know what it means to struggle every day with people who ask you why someone is not working the way it used to be? Do you know what it means to answer why features are missing? Many companies are not as flexible as a company like Atlassian. Come on - start listening to the big licencees as well and not only the small ones who don't care about migration.

3) Thanks for bringing up the migration thing! THIS IS EXACTLY the point. I actually find you proposal cynical to propose to migrate. We talked with Sven exactly about that. IT IS IMPOSSIBLE.

• The new greenhopper misses tens of features of the old one. You cannot MIGRATE running projects into the new greenhopper as long as it not fulfills the old functionality. It became a nightmare for many of our teams. My team worked months with the new greenhopper because I persuaded and actually "sold" it to them - I was always positive about that. Now, after several months of struggling, in the last retrospective then team decided to go back or drop greenhopper alltogether in future. Many more in my company and my clients are about to drop JIRA and Greenhopper alltogether if you are not adding all old features at least BEFORE you add new ones.

• There IS NO migration path. Please stop telling people they should migrate! You can start from scratch with a new project but not migrate. Neither you can migrate Sprints from the old classic board nor EPICs. This would become tens of hours for me and still does not provide what I have currenlty. When I moved over (which I did) it took me days and weeks until it finally "somehow" worked but it did not fulfill the purpose as it did before. I really talk from experience - I HAVE done it.

• The new greenhopper is much more restrictive than the old one (except the sprints). It limits sprint names, it does not allow me to change sprint beginnings and ends, it has no wallboard gadgets, the sprint burndown has less curves than the old one, the charts overall are less flexible but we need that flexibility and many many more points. Overall: "Individual and actions OVER process tools": The new greenhopper makes the team use the tool as it is supposed to be - this is not what agile is about!

I really could go on like this. Stop trying to defend yourself! You implemented good ideas in the new greenhopper (yes, you did) but please admit that it is NOT done yet. Start working on providing all the features that are in the old one as well, then please add new features.

Honestly, even though you attract new customers, you are definitely losing your customer base to competitors currently - This is indeed a fact; I can tell you because I know the community around me and many customers and this is what I am currently hearing.

I offered several times to talk (not write) to you. I sacrificed days and weeks of work writing constructive comments, I talked hours with Sven Peters at the last conference. It seems to me you don't understand that you just let down your current customer base because you are not providing a migration path. If I did that to MY costumers they would just fire me as a consultant.

Please, really, address the migration issue and make sure, you implement all old functionality first: STOP STARTING, START FINISHING.

"One more thing": From now on I probably become quiet as I think the time invested does not have any impact on atlassian. If nothing changes over the next weeks I will definitely tell everone in my community to migrate... to a different product.

cheers
Stefan

Hi Marco, Rainer, Stefan,

First, thank you for your thoughts and passion - we love it. This is what gives the GreenHopper team purpose.

Rainer, you explain that you have "custom coding for automatic issue links, status synchronization, custom field inheritance, effort accumulation and reporting". I can completely understand why you went down the path of custom code, our Epics functionality in GreenHopper has been lacking since day one.

As you are one customer with this custom code we are not in the position to make an exception that would add additional confusion and cost (to the administration interface, in the business logic, in the unit tests, etc) to all customers. I recommend that you await the release of Epics out of Labs and at that time explore steps for a manual migration from your custom code to the new, supported, Epics functionality in GreenHopper. Do not upgrade GreenHopper until you have prepared this migration as it may very well break your custom code - although we can not be sure as we do not have the custom code nor the time to investigate.

To reiterate Shaun's point, "it's imperative that we deliver this functionality to those who need it. Epics are easily the most requested feature for GreenHopper."

We are addressing the deficiencies of the past. We would love to have you on board, providing feedback, passion and purpose to the GreenHopper team. Please migrate to the new GreenHopper as time permits you and your 2,000 users. speters would be happy to put you in touch with a local Expert to assist with the migration.

With that in mind I will close this request as 'Won't Fix'.

Thank you gentlemen.

Regards,
nmuldoon

Hi Shawn,

I was also at the conference last week which Stefan has mentioned in his comment.

Our company stands right in front of the decision if we want to use Jira+Greenhopper or to use a product of one of the Atlassian competitors.

At the moment the functionality from Jira+Greenhopper is quite intersting and a big step in the right direction for our company.

But on the other side, I think much more about the future and how Atlassian will support their customers, and in this particular case the customers of "legacy" products.
We are talking here about big issues and for the customers also a lot of money to follow your recommended strategy.
I would appreciate a constructive discussion like we had last week with Sven Peters to understand the pain points of those customers and
hopefully to find a way to solve these issues with Atlassian.

Kind regards

Marco

Hi Shaun,

you wrote "it's imperative that we deliver this functionality to those who need it". Accepted! TO THOSE WHO NEED IT, right?

I do suggest you'll simply make it optional - that little. If you just WANTED, you COULD do it ... and "particularly larger instances" would not be left out in the rain.

kind regards – Rainer

Hi shoehn2,

We really cannot stop moving forward, it's imperative that we deliver this functionality to those who need it. Epics are easily the most requested feature for GreenHopper. If you do not want to use this functionality we would recommend either not upgrading, upgrading and continuing to use the classic boards, or downloading and modifying the GreenHopper source to work as you wish.

I understand your predicament. I also understand the migration side of things, in the future we might provide an upgrade task to automatically convert the existing epics from Classic in to new epic links, but I'm hesitant because they are not the same and do not work the same way. For now it's better if users reconsider their use of Epics and optimize them for the new interface.

On the feedback front, both you and Rainer have raised that many times. I really would implore you to believe me when I say that we've reviewed thousands of feedback items over the past year, we've attended many conferences and spoken directly with hundreds of users. We really are focusing on the needs of most users but I understand this doesn't meet the needs of all users, particularly larger instances like yours. As I've said before, you really can feel free to stick with Classic mode until you are comfortable with the options in the new boards. We are working as hard as we can to deliver features that will attract all users over from the classic boards.

Thanks,
Shaun

Shaun, the main problem again is that there is no migration path. If you would have a functionality the transfers current epics into the new epic field, then the new epic functionality would work for me but currently you are breaking it when you move your current project to the new rapid board.

"I'd suggest you'll simply have to train your users not to use if it you don't want to. "
Do you know what it means to "just" train 2000 users? It gives us a nightmare - "us" is those who actually run GH and have promoted it in our companies to become successful.

Please, please, if you introduce new feature make sure you understand what impact it has for all "legacy customers" who helped you building the old greenhopper community and success. I would also ask you to get in touch with Sven Peters, Atlassian Ambassador, who joined an agile conference last week in Germany where he got a lot of feedback which is probably really helpful for you. I am happy to support him and you by providing constructive feedback.

cheers
Stefan

I'm pretty sure we won't do this. Epics are a key feature of GreenHopper so we're not going to remove the functionality or have it switched off.

In the next release of GreenHopper it will automatically create the Epic issue type each type GreenHopper starts if it does not exist.

I'd suggest you'll simply have to train your users not to use if it you don't want to.

Cheers,
Shaun