• Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      I believe that GH should implement a top-level team concept. Having multiple teams pull from a single project right now is cumbersome. (See: http://jaibeermalik.wordpress.com/2010/07/22/using-greenhopper-to-manage-multiple-teams-in-agile/) 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 could be reported but not associated with a team. Howver, then the coordination between what bug is in which project would be a nightmare. Enabling multiple teams within a single project, just like VersionOne and Rally is the right way to go.

            [JSWCLOUD-2849] Enable "Teams" as top-level concept

            Dear Jira Team,
            I also about to report a suggestion related to it. There MUST be a concept of Teams with designation and expertise in Jira so that we can better management the users and teams. Also, there should be a permission type, "Team Members". If someone selected this option in Permission Schemes, anyone in the team can access that functionality.

            We have 9 projects and if we do not want the team to see each other project, we have to create 9 Permission Schemes. If you implement Team Members and a permission type then one can manage multiple projects with one Permission Scheme.

            Best Regards,
            Rizwan Akbar

            Rizwan Akbar added a comment - Dear Jira Team, I also about to report a suggestion related to it. There MUST be a concept of Teams with designation and expertise in Jira so that we can better management the users and teams. Also, there should be a permission type, "Team Members". If someone selected this option in Permission Schemes, anyone in the team can access that functionality. We have 9 projects and if we do not want the team to see each other project, we have to create 9 Permission Schemes. If you implement Team Members and a permission type then one can manage multiple projects with one Permission Scheme. Best Regards, Rizwan Akbar

            200ok added a comment -

            +1 to this. We have multiple teams working on a single project and it's really hard to manage without very cumbersome UI. Having "Teams" along side versions and epics would give a nice Drag and Drop option for a planning board; then each team could filter by Team for their own rapid view.

            200ok added a comment - +1 to this. We have multiple teams working on a single project and it's really hard to manage without very cumbersome UI. Having "Teams" along side versions and epics would give a nice Drag and Drop option for a planning board; then each team could filter by Team for their own rapid view.

            Hi kevinshine, could you explain how GH 6 makes this worse than before?

            Teams as a concept have more of a home in JIRA than in GreenHopper. Implementing them in GreenHopper would probably be a problem in the future if we end up with teams in JIRA.

            Shaun Clowes (Inactive) added a comment - Hi kevinshine , could you explain how GH 6 makes this worse than before? Teams as a concept have more of a home in JIRA than in GreenHopper. Implementing them in GreenHopper would probably be a problem in the future if we end up with teams in JIRA.

            In GH6 this is a HUGE problem.

            Kevin Shine added a comment - In GH6 this is a HUGE problem.

              Unassigned Unassigned
              evan.leonard Evan Leonard
              Votes:
              19 Vote for this issue
              Watchers:
              13 Start watching this issue

                Created:
                Updated: