On this page:
For more Q&A on GreenHopper see Atlassian Answers.
GreenHopper 6 introduced a whole new user experience to GreenHopper. The team worked on this for 18 months and released over 30 versions to customers participating in our beta program, known as GreenHopper Labs. The Classic mode includes the Planning Board, Task Board, Chart Board and Released Board. These boards are now available under the "Classic..." option from the Agile menu (see below).
Going forward all development effort will be focused on the new GreenHopper, allowing us to provide great new functionality such as multiple project support, scope change in the burndown chart, swimlanes, sharable URL's, and a whole lot more. Check out GreenHopper 6 What's New for more information.
Over the coming months we will continue to add great new features to the new boards that will further encourage users to switch from the classic boards to the new boards. We do not intend to retire the classic boards until they are no longer used by the majority of users.
In any event, the Classic boards will not go EOL until at least 30 November 2013. We will provide a further update regarding the EOL closer to that date.
At present the key aspect of the Classic boards that is not available in the new boards (formerly known as "Rapid Boards") is the ability to configure the fields displayed on a card. For more on the configuration of cards see "Can I configure the cards' fields that will be visible, in the work board?" below.
Another aspect of Classic that will not be available in the new GreenHopper is the ability to nest Fix Versions and Components. The hierarchy for Fix Versions, and the associated Start and End Date, has been replaced with a new Sprint object. Sprints have a Start and End date, and this frees the Fix Version field to be used to represent the actual shipping version of your software that a story/bug/etc was present in. As the new boards differ from the Classic Planning Board there is no Fix Version / Component / Assignee mode available.
The new menu structure is great, but the majority of our users are still using the Classic boards. We only have a couple of groups using the Rapid Board. They would like to use the new functionality, but it would disrupt the whole company if the menu structure changed when we upgraded.
There is no setting for this. When existing users click Agile they will be taken to the last board they visited – be that a Scrum / Kanban board created via the page, or one of the Classic boards (Plan, Task, Chart, Report). The user can then change the board they are on via the dropdown within Classic:
A number of gadgets are compatible with the new board, including the Sprint Burndown Gadget, Days Remaining in Sprint Gadget, and Wallboard Gadget. In future we will be making other gadgets compatible with the new boards.
I've been using GH 5 for a while now, and have all my previous sprints organized based on the fixVersion. Now with GH 6 this no longer seems to be used (except in classic views).
This means all my historical data is no longer available in the UI. Is there a good way to get this data into the new system, or will I have to recreate all my sprints manually and do a bunch of filtering to pick out the stories and manually add them to the appropriate sprint?
There is no automatic migration from Fix Version to Sprint.
We recommend you start by creating a new Scrum board for your team, exploring the new board and then starting the next sprint on the new board. Historical data will be available via the Classic boards.
Today, only the issue, the description, the priority and the assignee are visible, but I want to see the original estimate and the remaining estimate.
No, it is not possible to configure the cards. However, in GreenHopper 6.0.3 we introduced the ability to configure the detailed view of an issue.
You can also configure the colour of cards using a variety of criteria, for instance with JQL:
The need for the auto assign feature in GreenHopper has mostly been driven by the fact that the JIRA default workflow has a condition on the transition from 'Open' to 'In Progress' that allows only the assignee to perform the transition.
In many cases you may want your administrator to remove this restriction. Your administrator can also configure the workflow to automatically assign it to the user performing the action by adding a 'Post Function':
This approach is more powerful than the Classic board Auto Assign behaviour because it will take effect everywhere in JIRA (even transitions initiated from the JIRA View Issue screen).