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:
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?
I would go either of these two routes:
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.
Thanks. I ended up defining 1 project per component and one board per team. There seems to be an interesting interplay between sprints, projects and boards that I hope to understand as we use the tool. And I was surprised to find that I can't add estimates to tasks. I guess we'll just consider everything to be a story for estimating purposes.
At Atlassian, we believe in our own products – that's why we use them, even at the enterprise level. Doing so gives us first-hand experience of how they perform at scale; to do this, we monitor each ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs