Hello,

I am closing this issue as Obsolete. For some time now it has been possible to create a saved filter based upon a label custom field (e.g. 'team = dreamteam'). One can then add that saved filter to a context, and create a context for each team.

In the suggested scenario you will have one JIRA project for all teams, you can retain the component field for components, you can view the burndown by team, and you can quickly assign an issue to a team with the 'l' keyboard shortcut.

One remaining issue is having capacity and markers by teams, this is covered in a new issue which was recently raised - GHS-2849.

Thank you.

Regards,
Nicholas Muldoon

All of these custom field work around to enable a "team" concept seem fairly weak. I believe that GH should implement a top-level team concept. Having multiple teams pull from a single project right now is cumbersome. This should not require custom setup to achieve. And it is frustrating our adoption. Having separate project per team does not work either, as then there would have to be a separate "bug project" where issues reported but not associated with a team would be logged, and then the coordination between what bug is where would be a nightmare. Enabling multiple teams within a single project, just like VersionOne and Rally is the right way to go.

Hi Rob,

The component field, which we are already using for our software component and a group picker custom field option seems cumbersome. All users would have to set their own filters?

Not really, in 3.2 we are introducing the shared contexts.
The project administrators will be able to create contexts based on its own JIRA filters (no need to be public) and then share it to the project team members. That will answer the cumbersome of these options.

Also if you do not have a large number of teams (2 to 3) you could reuse the "Master Setting" to actually represent your teams.
e.g.

• Release 1 (FixVersion)
  • Sprint 1M1 (FixVersion with master Release 1)
    • TEAM A - 1M1 (FixVersion with master Sprint 1M1)
    • TEAM B - 1M1 (FixVersion with master Sprint 1M1)
  • Sprint 1M2 (FixVersion with master Release 2)
    • TEAM A - 1M2 (FixVersion with master Sprint 1M2)
    • TEAM B - 1M2 (FixVersion with master Sprint 1M2)

That would be a very efficient solution if you dont like the 2 others.
You will be able to easily print your Release charts, Sprint Charts, Team Sprint Charts.
And will help to easily assign stories, task ,bugs etc to a given scrum team

Hope this helps.

Cheers,

Greenhopper support suggested two workarounds. The component field, which we are already using for our software component and a group picker custom field option seems cumbersome. All users would have to set their own filters?

Since we have a relatively large organization with a scrum of scrums running with 8 teams now we would need something more integrated within greenhopper to allow the tool to be used effectively by more than one team. Here are some thoughts on the required functionality . .

Within a version(sprint) we'd like the ability to

• have a quick view by team of their stories and progress, similar to the view displayed on right side of planning board by component.
• display the task board for a given scrum team as well as the taskboard for the overall sprint
• display the chart board for a given scrum team as well as the chart board for the overall sprint.
• ability to easily assign stories, task ,bugs etc to a given scrum team

For unscheduled work
-display the planning board by scrum team so they can individually do their own planning

Hi Ian,

Have you looked at the component options?
Having a component to define a scrum team and then defining JIRA filters based on these components.

If you are already using the components for another purpose you could add a group picker custom field and base your JIRA filters on it.
Then in your context reuse these JIRA filters to have boards for specific scrum teams?

Let me know if that could suit your request.

Cheers,