Multiple teams, JIRA best practice? (JIRA Server 7.4)

[Matt Stephens]

Hi all!

Looking for advice on best practice setup please.  I've joined an organisation that already have JIRA setup but there is an opportunity to restructure as part of some other changes.

The org setup roughly is like:

* A core product A - an 'Authoring' tool

* Several (2 currently, but may be more in future) customer centric custom versions of product A

One scrum team covers both the core and customisations for product A

* A core product R - a 'Runtime' tool that consumes the output produced by product A – with a dedicated scrum team

* Several (2 currently, but may be more in future) customer centric custom versions of product R – each with a dedicated scrum team

So, in other words a single customer project will have:

* Product A – core version + customisations – delivered by a single team ‘A’

* Product R – core version + customisations – delivered by core team ‘R’ and customer team ‘R-C1’, ‘R-C2’, etc

Hope that makes sense so far!!

At moment we have a slight mix of how JIRA has been structured.  For the simple cases there is a dedicated JIRA Project with its own Board.  Exceptions being:

* We also have Customer facing backlogs – for example ‘C1’ – for them to raise bugs, general discussions etc.

* Product R customer team – has a Project ‘R-C1’ for example, with a Board that consumes that project, filtered on Component ‘R’.  This team are cloning bugs raised in C1 in to here to manage them.

* Product A – has its own Project ‘A-Core’, and has stories in Project ‘R-C1’, and has a Board that consumes both those Projects, with R-C1 filtered on Component ‘A’, and also C1 (I’m guessing filtered in some way – maybe component as well).

Moving forward, I’d like to know if there is some best practice advice on this.  Should we have separate Project for each Team?  Or one Project covering everything and use some filter for each team?  Etc…!  What is the way that JIRA will work best?

[josh · Accepted solution]

I do both on my instance. Sometimes separate projects for each team, sometimes unified with a field determining the team.

It really depends on the product. One reason to have one project is to unify the versions and components, and it will help ensure that all of the data can be easily found.

But one project does make it harder for people to work. It requires discipline (or strong jira workflow conditions/validators) to ensure the team is accurately changed. And does an issue transition from one scrum team to another? It can cause board contamination because the sprints from one team will show up on the board of another team.

One definite recommendation of mine is to make it so your projects are designed with a sunset in mind. Projects shouldn't live forever, they just get too cluttered.

You also have considerations of permissions. If your customers should only see some content, then my recommendation is separate projects.

Project scope is constantly a under discussion with me as well, each situation, each team and each product may need something slightly different. Hope some of this might have helped.

[Matt Stephens]

Thanks @josh, I guess unfortunately the answer (as often seems the case with JIRA) is 'it depends'!  Doesn't make it easy for someone new and explains why I'm seeing so much confusion in the setup I've inherited - people have clearly gone one way and then realised it wasn't working and changed direction, but it's left things in a bit of a mess!

I think my conclusion is that fewer changes is probably better.  Everything is already separate projects apart from one (which contains 2 teams work), and it turns out the customer has access to that one so we can't change that (they're not an easy customer to work with so there is zero appetite to try and educate them to do something different!)