Greenhopper navigation problems

[Dmitry Nechayev]

Jira version: 4.4.1 Greenhopper version: 5.7.4

During GH adoption myself and my project users have noted a number of navigation/usability issues that in general had led to a negative perception of the tool and limited its use in the team. It would be great if some of the issues noted below have suitable workarounds or have been addressed in subsequent versions

1) Planning/Task board: No clear navigation path back from the Issue View or Edit modes back to original Planning/Task board view. As a workaround, we invoke again Agile/Planning|Task Board menu option but this causes full reload of the page. Besides, if a Fix Version was changed for an issue during the preceding edit session, this causes Version field to change in the version selector on top of the board and produces a different list on the Board. Not expected behavior. The problem with expanding/collapsing sub-tasks during the re-draw was noted in another GH ticket - we still intermittently experience it too, clearing the cookies does not help

2) Aforementioned workaround (going back to Agile/Planning Board menu) generally does not work in release planning mode when we work with a list of epics and invoke a window with a list of issues for an epic. When we do any operation on an issue from that dialog box (view, edit), there is no direct way to return back to a window with a list of issues for an epic - from which an operation was invoked.

3) We did not find a way to load GH Planning/Task board with a target project/context/version. All of these parameters have to be set manually, one at a time - every time with a full page reload. As a result, an operation as simple as changing a status of a task takes too many clicks and too much waiting time to get to.

[Martin · Accepted solution]

Thanks for your detailed reply.

Editing in the Rapid Board has an approach that would probably better suits your needs (when all fields are editable) but I assume for your Scrum usage it doesn't have everything you need just yet.

[Dmitry Nechayev]

... besides, I am no longer able to work with Jira client because of https://jira.atlassian.com/browse/GHS-4297. This 5.8 upgrade is increasingly looking like a wrong choice

[Dmitry Nechayev]

We just upgraded to GH5.8 and I was eager to see how Rapid Board addressed all those issues. So far I did not find a way how, at least, to get an equivalent level of functionality to what we have been using with Planning and Task boards. I did not find how to configure Rapid Board cards, how to view epics'content, how to make a compact list. Overall it seemed more counterintuitive and less usable. I wonder if it would be possible to address most critical concerns with existing functionality (like having URLs for specific views/contexts) rather than inventing new functionality of dubious purpose

[Martin]

Dmitry,

1. Have you tried editing the issues in the Planning Board? The issue cards (3 different ways to view card, summary, list) can be customised to show the fields you are interested in viewing/editing. If the field on the issue is editable then this can be done in-place using inline-edit, just click the field and edit. This would be the preferred way to edit or view an issue within GreenHopper without the round-trip to JIRA's pages.

https://confluence.atlassian.com/display/GH/Using+Planning+Board+Views

2. Have you tried working with Epics while using the Scrum template? This has benefits in the way Epics are handled. When clicking an Epic 'label' all the children are shown in a dialog and so changes can be made without losing your viewing context.

https://confluence.atlassian.com/display/GH/Working+with+Epics

3. The behaviour of the boards is to show the last used project/context and the Planning/Task boards do not have permanent links. This is one of the features we have added to the new Rapid Board, where all states can have permanent links (to bookmark/favourite/share).

https://confluence.atlassian.com/display/GH/Using+the+Rapid+Board

[Dmitry Nechayev]

Thank you for your reply!

1. Yes, we are using inline editing in the Planning Board. It does help in certain cases, but most heavily edited fields are multi-line Description and Acceptance Criteria field and editing them inline is not really usable

2. Yes we are using Scrum Template. The problem with Epic children window is not in the context change though. Consider the use case: during a release planning, Product Owner opens epics one by one and for each epic enters child stories. Child stories are being edited from the same Epic children screen. Completion of an Edit session brings a user to the View screen from which it is only possible to return to the original list on the Planning Board. Then the current epic should be located again, Children window invoked and the next story in the list taken for editing. Not really usable. I understand that this hits the same navigation limitation that exists between Jira and GH screens

3. I understand that Rapid board will address this and have no more questions. Will wait for GH 5.8 to be deployed

Thank you

[NikE]

There are a lot of new features and functionality being added in Greenhopper v.5.8.x, but I'm thinking that the issues you are describing might be browser related. If you are using Firefox 3.5/3.6 or IE7 - there are some pretty serious navigation and performance issues. If you are using one of these browsers you will very likely find everything works much faster and more smoothly if you switch over to a newer Firefox or Chrome.

Greenhopper will be updated to v.5.8.x in the OnDemand suite in the near future, although I do not have a date/window for when that will happen.

[Dmitry Nechayev]

Thank you. Will wait for GH 5.8 to be updated to see whether it fixes these problems. One thing is sure is that the problems listed above are not browser related - these are purely functional problems related to a lack of clear navigational path between GH screens - as described above