Folks,

This has been addressed with the Rapid Board in GreenHopper 5.8. Rapid Board development continues, specifically around the scrum use-case and improved epics in the short term.

Thanks,
Nicholas Muldoon

Hi Ert,

Please take a look at the Rapid Board. It will be out of Labs in a month or so, in the meantime it will be a much better workaround than the ghost stories you are using today.

Thanks Ert.

Regards,
Nicholas Muldoon

I'm with gbrauer1 on this one, "The 90% feature that we are looking for here is the ability to use drag-and-drop to set strict issue order on issues across projects." – In fact, just the ability to rank, whether or not drag-and-drop was possible, would be useful. I voted on GHS-663, too.

Right now we're creating ghost/clone stories in a master unified project that are linked back to the story in the other project. A workaround but hardly an optimal solution.

We need this as soon as possible. Without this function Greenhopper is not very useful

Same for me, we need this feature. We have a small team of ten people working on multiple project. Be able to able to manage all project in one place would be great!

My company is in desperate need of this! Right now we have about 10 different software projects, but we constantly run into sprints that have tasks spread across multiple projects. Having to switch between projects for the same sprint is causing confusion to our sprint members and even our scrum master. The burn down chart becomes worthless. We have had to go to the extreme of creating a single project that has the tickets for all of our other projects, but this is just slop.

I voted for this story. Right now the various teams use the task board during our stand-up. For teams that are working on one project this works great. For the teams that need to go between projects (the majority of mine) it still works, but this would be a huge help.

Idea: Use an additional ranking field to enable ranking across projects, pull one PB and then sort by this rank field. This will not impact ranking for individual projects.

One customer reports another use case: sorting by Rank in Issue Navigator across multiple projects. As of now, sorting by rank across multiple projects will give you incorrect ordering.

And actually, now that I think of it, we have plenty of use cases for the rest of GH across projects, but still the cross-project drag-and-drop issue ordering would make an even wider audience happy.

The 90% feature that we are looking for here is the ability to use drag-and-drop to set strict issue order on issues across projects. We don't really have as strong of a use case for the rest of GH across projects, but the GH implementation of drag-and-drop issue ordering is pretty close to ideal except for the lack of cross-project functionality. If the only way the GH team would implement drog-and-drop issue order across projects would be to properly integrate all GH functionality as cross-project capable, then I offer the following opinions:

• How do you schedule issues in to a fixVersion? Do we require the same fixVersions for all projects? Components?
• Do we require the same Master/Child relationship for versions/components? What about differing Start and Release Dates?

These problems would really not exist if a single fixVersion entity could exist on multiple projects, which is a separate but related missing feature in JIRA. The workaround for GH would be to implement a mechanism that tracks "sameness" between fixVersion entities. (Such a feature would be fantastically awesome on its own for searching purposes, even if you didn't use that work as a platform to implement the feature described in this issue.)

With that "sameness" mapping, it would be possible for GH to always display the union of all fixVersions on projects represented by the displayed issues. GH would also then be able to create a new fixVersion entity on a project that is the "same" as a fixVersion from another project when GH is used to assign an issue to one of those fixVersions that doesn't already exist on that issue's project. Master/Child relationships and start and release dates would automatically match because they would already be known to be the "same" fixVersions, therefore living in the same hierarchy.

• What happens when there are different issue type schemes for different projects? For instance, Bug vs Defect?

I'm not sure I quite follow where this matters, but I think you would just need to set the behavior globally instead of for each project. If you're talking about two entities with different names but having the same meaning (as in "Bug" and "Defect"), then I think that's a problem for the JIRA administrator, not the GH developers.

• What permission scheme do we use? What is displayed if some users have permission to view/edit/schedule all issues from all projects and other cannot?

You just display what the current user has permissions to see. This could be confusing if a user is not configured to see the right issues, but again, that is a problem for the JIRA administrator of that system, not the GH developers.

• GreenHopper charts are generated dynamically for the most part, how do we ensure everyone is looking at the correct information?

You're talking in terms of permissions? That's just a call you will have to make. Either the charts reflect what the user has permissions to see (see my answer to the previous question) or you override the permissions and make the graphs reflect the state of the world. This problem is not unique to GH... JIRA's built-in charting has the same problem and they went with the former solution, which seems fine.

Hi Ryan,

The short term roadmap takes GreenHopper through the next 6 months, in this case to Atlassian Summit.

While there is no technical limitation to multiple project support across GreenHopper there are a number of hurdles we have to overcome. Some of the questions we have been asking ourselves include:

• How do you schedule issues in to a fixVersion? Do we require the same fixVersions for all projects? Components?
• Do we require the same Master/Child relationship for versions/components? What about differing Start and Release Dates?
• What happens when there are different issue type schemes for different projects? For instance, Bug vs Defect?
• What permission scheme do we use? What is displayed if some users have permission to view/edit/schedule all issues from all projects and other cannot?
• GreenHopper charts are generated dynamically for the most part, how do we ensure everyone is looking at the correct information?

No doubt many more questions will arise as we explore multiple projects further.

Our concern revolves around the flexibility in JIRA and how we accommodate that flexibility within GreenHopper while still making multiple projects a compelling offering. If you have any suggestions they are most certainly welcome.

Thank you Ryan.

Regards,
Nicholas

Register now for Atlassian Summit 2010, June 9-11 http://summit.atlassian.com

Hi Nick,

Thanks for the feedback. But what does that actually mean? What sort of time period does the short term roadmap cover, months, years?

Ryan

Hi Ryan,

Multiple project support for GreenHopper is not on the short term roadmap.

Thank you.

Regards,
Nicholas Muldoon

Register now for Atlassian Summit 2010, June 9-11 http://summit.atlassian.com

Hi Gregory,

Please vote on this issue - GHS-663, As a GH user I would like my Planning Board to display multiple projects at once.

Thank you.

Regards,
Nicholas Muldoon

Register now for Atlassian Summit 2010, June 9-11 http://summit.atlassian.com

Having voted for and commented on tens of issues while using JIRA, I don't think Atlassian actually follows this JIRA (amusingly). Perhaps our concerns are better voiced elsewhere?

Also, I don't care too much about seeing multiple projects on the Task Board, but we are pretty desperate for the ability to see multiple projects on the Planning Board. I can't find a ticket for that. Do the Task Board and the Planning Board go hand-in-hand as far as this issue goes, or should I break that request off in a separate ticket?

Hi,

We are currently evaluating different issue tracking systems, and while Jira is at the top of the list for many things the inability to have multiple projects on the planning and task boards is unfortunately pretty much a deal breaker.

Is there any word on if/when this will be implemented?

Ryan

+1

I would be very happy to get such a functionality!

This would be a real help until (if ever) attlassian implements sub-projects (and greenhopper supports them as well): http://jira.atlassian.com/browse/JRA-12241

We need to split projects into several projects and group them with a category.

This would be helpful in planning as well. We schedule tasks across projects and we need to take into consideration tasks from multiple projects when deciding on what to work on.