How to best handle multiple components and multiple teams?

Andrew Miller3

Just starting a new project and the client has decided to use jira and green hopper. As we build out the project we'll be working on several components, each with it's own git repo. And we'll be split into 2 (maybe 3) teams, each focusing on it's own components with perhaps independent release schedules.

So I'm looking for a recommendation on how to should handle multiple components and multiple teams in greenhopper; I can se a few options:

• only one project
• one project per team
• one project per component
• ... other optins?

I'm brand new to green hopper so I'm not sure how these options play out with agile boards and sprints. Any advice for us from folks who've been down this path before?

Pascal

I would go either of these two routes:

1. have a project per component, or
2. have one big project

The advantage of the first one is that it easily keeps each components with its own release schedule seperate. No interference whatsoever. Also it allows you to administer the versions of each component separately.

The second option I would go for if the components are rather tightly coupled and it is hard for some people to report issues directly for the correct component. In that case one project in which a tester can report his issues is easiest. You can create scrum boards per component. That way each team has his own scrum board with his own sprint planning (which you could consider equivalent to release planning, although you would not use the actual release administration of Jira in this case). In this scenario it is not possible, though, to easily administer the appropriate version per component. But then again, you might not need that.

Finally, I would not go for the "project per team" setup, since team structures can be ratehr volatile and if business people are to report issues, then I'd rather have them report issues they find in a system then have them think of what team needs to solve the issue.

Hope this helps.