Hi Gregory,

Thanks for sharing details on how you use GreenHopper.

GreenHopper will enable to achieve what you are looking for today. The context is applied to the statistics which are configured - be that time, story points, etc.

Should you have any further queries about that feel free to email me (nmuldoon@atlassian.com).

Thanks Gregory,
Nick

We have a single software development project with enough developers to be split into multiple development teams (specializing in UI, back-end, bug squashing, etc.) In our scenario, using a single JIRA project to track this work makes sense, and we don't necessarily need multi-project support for this in GreenHopper. We use GH Contexts that use a filter to provide Planning/Task Board views of issues specific to each team. However, each team would like to be able to use the Stats bars to total up, say, Story Points for their team only (i.e., context-specific stats bars.) Is there a way to do this today, or would the proposed implementation of multi-project support in GreenHopper allow this somehow? Would it require that we split our project into multiple projects (one per team)? If so, would there still be a way to easily view the aggregate status of the project as a whole?

Andre, Melanie, thank you for your comments and suggestions. Very helpful!

We will explore multiple project support in GreenHopper post-Summit and I will update this issue with further details as they come to light.

Any other thoughts and suggestions are most welcome as that will ensure we have a clear understanding of the common needs our disparate customer base.

Thank you.

Regards,
Nicholas

+61 2 8916 9125 (Australia)
+1 415 408 6147 (US)

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

We are a (smaller) service agency with many clients and projects going at one time. Mixed in with the project work is a mix of support issues. We have one person who schedules (or allocates) all projects and adds in a percentage mix of support time. (That's me, in addition to managing the bigger projects.) We project managers have shared team members ("resources") and we need to see what other projects or tasks are assigned to each of the developers.

We use the GreenHopper plugin as a kanban board, and it works fabulously per project. We don't work on deadlines, rather we work on prioritization. I communicate priorities by a list of tasks/projects emailed out to the team. This is purely manual right now because I cannot see this information in GreenHopper.

Priorities shift and I need to be able to change the order of tasks, across projects. I use Versions in JIRA to set up arbitrary sprints for each project. It is basically a time bucket. Our situation could easily give up the flexibility of the current Version functionality and standardize on one Version setting across all JIRA projects. For instance, if there was a global setting for versions, I would be able to easily see what work was planned for that week or month, and arrange the priority. Anyone could login and view the planning board or their own task board.

I'd love to hear what you think, Nick. I'm not a technical person but I love using JIRA, and the company today uses it because of my recommendation. How could you help us further gain productivity and collaboration from GreenHopper?

Regards,
~Melanie

We are currently evaluating JIRA/GreenHopper, and are impressed overall, but this one issue is preventing us from implementing.

Whilst we appreciate that there are many things to consider, could we suggest the following:

On the planning board, allow users to select more than one project.

If two products (that were selected) have the same version, show a combined view in the 'versions pane' on the right hand side of the screen, i.e. roll-up the stats for both products into one.

This will allow us to create something like:

Project A, with versions:
Release 3
– Sprint_Apr (Release 3 as master)
– Sprint_May (Release 3 as master)

Project B, with versions:
Release 1
– Sprint_Apr (Release 1 as master)
– Sprint_May (Release 1 as master)

When we do our planning, we select Project A and Project B, and select 'Unscheduled' (in fact it would probably be OK if you only show Unscheduled in the drop-down when multiple projects are selected, as this avoids the confusion of 'mixed' version numbers for multiple projects - our aim is to look at our combined backlog and assign it to an iteration).

Thus we get a combined list of unscheduled cards, and we can see 'Sprint_Apr' and 'Sprint_May' on the right hand side. We can prioritise our combined backlog, and assign tasks to the iteration we require.

As we assign tasks, GreenHopper will be able to work out which actual version to link the task to (by looking at the Project under which the task was logged), and Component shouldn't be an issue (again this would have been assigned when the tasks was logged, and we are not interested in changing it at this stage).

As for user rights, obviously it would be required that the user doing the planning must have rights to both projects. If he didn't, he would only see 1 project, and will not be able to select a second project. In our case we have 1 team, that works on both projects, so everybody will have access to the same projects, and therefore is assured of looking at the same information.

I understand that the above might not be sufficient for everyone's needs, but I think it will add huge value for a large number of users - as the previous poster said, maybe focus on what you can do right now, even if it is not perfect?

Nick,

You offered the same comment to, or on, GHS-705.

This sounds, to me at least, like you're over complicating the issue and that even a "lighter" version of cross-project GH would be widely accepted and welcomed by the community at large.

I, for one, would urge you to examine this issue from a "what can we do" perspective as opposed to the current "why we can't do it" approach.

Respectfully.

tmcg

Hi Art,

The short term roadmap takes GreenHopper through the next 6 months, in this case to Atlassian Summit. Multiple project support is not on that roadmap.

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 Art.

Regards,
Nicholas Muldoon

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

Any idea on when this feature will be scheduled for work?

Our Company really needs this capability to be included across the planning, task and chart boards.

Hi,

We are currently evaluating different issue tracking systems, and while Jira is at teh 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

Hi Chandru,

It is not scheduled on the short-term list.

Regards,
Nicholas Muldoon