Using GreenHopper to manage multiple teams in Agile

Managing single team in a project using any such tool sounds like a simple job but imagine a project with multiple teams having same/different backlog and accordingly sprint/milestone releases etc. Having a tool which provide a lot of flexibility and customization to help in managing all these requirements for different teams and management too seems like very challenging task. The question is to find the best solution which fits to everyone involved in the process. In this post we will explore such different requirements and will see how we can configure GreenHopper to meet such requirements.

Think of some general scenarios where team members and management might have some questions like,

• What if there are multiple teams in a project?
• What if all these teams have parallel releases for some major/milestone release?
• What if all teams share the common backlog?
• What if all teams should have their own backlog which is just sub set of whole project backlog?
• What if all teams work on different functionalities?
• What if all teams share the same code base repository?
• etc. etc.

The basic question we are targeting here is that how we can use Greenhopper to configure the tool for multiple teams and choose the right implementation approach which suits best to the teams.

Complex Scenario?

Simple scenario the project consist of single team and like any other jira project, which can be handled by single jira project. Think of complex situation where you have multiple teams working in the project.

greenhopper-red-green-blue-as-single-team

Let’s say there are three teams – RGB: Team Red, Team Green and Team Blue. And you some of these requirements in the project,

• Each team having own backlog information Backlog Team Red, Backlog Team Green and Backlog Team Blue
• Each team backlog is part of complete backlog
• You need proper reporting and sprint information for each team
• Different team members in each group

Different Approach?

There are different options you can try to configure GreenHopper for multiple teams. Among which are,

• Team drop down Field
• Version Hierarchy
• Component Hierarchy
• Team Dummy user/Groups

Let’s go through each approach separately and analyze the pros and cons for each approach.

Team drop-down Field

You can create a custom field drop down with values, Team Red/Green/Blue. Some of the pros and cons are,

• Custom Field having values of all the teams
• Unplanned work will remain with no team value selected
• Based on team selection, each team backlog can be separated
• Hard to plan issues and you need to set team field value each time during planning
• Not very elegant solution
• More work in planning
• Team information will be independent of version/release planning.

Version Hierarchy

You can create Version Hierarchy in GreenHopper. You can create versions like a usual way we do in Jira and then can create the hierarchy for the same in GreenHopper view. Based on the project requirements you can create version hierarchy to match the independent sprint releases for each team or parallel sprint release for each team.

Independent Sprint Release for each team,

Milestone 1
-Team Red M1
–Team Red Sprint 1 M1
–Team Red Sprint 2 M1
-Team Green M1
–Team Green Sprint 1 M1
–Team Green Sprint 2 M1
…

Combined Sprint Release for each team,

Milestone 1
-Sprint 1 M1
–Team Red Sprint 1 M1
–Team Green Sprint 1 M1
–Team Blue Sprint 1 M1
-Sprint 2 M1
–Team Red Sprint 2 M1
–Team Green Sprint 2 M1
–Team Blue Sprint 2 M1
…
Some pros and cons for the approach are,

• More flexibility
• Need to decide the right version hierarchy which will fit for the project sprint/release planning
• Can be easily changed with bulk operation, move all open stories from one version to another
• Less work in planning
• Version management much easier with Jira/GH both
• Need to create right versions in each sprint

Component Hierarchy

Similar to versions, you can also create version hierarchy with GreenHopper. Like versions, componenets can also be created in Jira view and the hierarchy can be managed with the GH view.

To create component hierarchy, you can assign a particular top component to a team and based on that you can assume that the functionality under that particular component belongs to one team etc.

• Assumptions need to be made
• Inter team backlog items are hard to manage
• Wrong selection of component or change won’t be easy to be accommodated
• Components are used to represent functional requirements

Team Dummy user/Groups

To represent the backlog from each team, create separate groups for the team members like jira-team-red/green/blue-all and all the tickets assigned to any member of these groups belong to their backlog.

You need to create dummy users like jira-team-red/green/blue-dummy and all issues in there respective backlog is by default assigned to this user. This user is part of above group.

Creating team dummy users and groups will directly map stories to teams which may cause problem in giving clear picture of backlog if we change the team user from one team to another.

• No extra information required to be stored in ticket
• One time job to create dummy user and groups
• User management can be done using external application like crowd
• Approach not flexible if the user jump from one team to another, it will give wrong indication of backlog from one team to another one.

Choose the right approach?

There is no strict rule like which approach we should use. We should go ahead with the one which fits best to the team and easy to use. Ideally if you using GH view, there should be no need to go to Jira view to update tickets/Story/Task etc. We need to select the one which requires very less efforts and fits best in practical scenarios. You can also configure the context for the GH view, the way you want. Based on you filter criteria and other things you can create the kind of dashboard you want for the team.

Please feel free to share your experiences while working with the multiple team set up or using GreenHopper in similar scenarios.