Multiple teams, same department

[Meytal BM]

Hi,

I am debating whether to open multiple Jira Software Projects or a Single one for the multiple teams.

A few things about the teams:

Hierarchy: Department -> Squad/Units -> Teams

The departments vary from R&D to Security, working on different projects and processes, but sometimes they have dependencies.

And within let's say Security Unit, there are multiple teams there and again work on  different products/service and processes, but sometimes they have dependencies with other teams/departments.

Also on the department level, i would like to see the big picture of all the squads/units.

Note that some of these teams, some of their requests derive from Jira Service Desk (SD), yet haven't decide whether to move these requests to Software, or leave them in SD due to the Agent licenses costs.

I know there is pros/cons to both options, yet would love to hear you feedback on what works for you in these cases.

[Meytal BM · Accepted solution]

For now, for each team (aka Squad) i have decided to go with a diff project. There are teams that we're still debating whether to create a diff project for their sub-team, but I will know later this week depending on a design session I will do with them.

As for dependencies:

1. We have a cross project identified (aka custom field) that if it is set on an epic, we know its part of a larger project. Then we can use Looker or other reports to show the portfolio view.

2. Each team who has dependencies will need to collaborate on a quarterly level and if needed, more. Either way, in Jira they will each open their own epic with that cross identifier.

3. Dependencies within the same team, but diff sub-team, there will be one epic owner, but the stories will be assigned to specific person, and we have another custom field "teams" so we can also see on a team level the item(s).

So far, I have tested some of this, but I am literally at the implementation stage of all the teams/squads, so once they start using it (in the next month+) we'll find out what works great and some areas that need adjustments.

Hope this also helped you and others.

[Meytal BM]

Thanks again @Warren .

I think it makes sense (to me at least) that each Squad has it's own project regardless how many teams it has within that Squad.

As for dependencies, although I fully agree that collaboration is the key, there still needs to be a best practice on how to reflect that within the tool. 

Let's say we need to develop a Report. This reports requires different teams from different Squads. In this case there are various way to go about it:

1. Each Squad/Team open their own Epic associated to this Report, then add a "label" that reflects these Epics are associated to this "Report". I am not keen on using Linked Issues in this case. Is there any other way?

2. One team takes ownership and opens a single Epic for this "Report" within that Squad's project, then opens stories for other Squads. The advantage is that it's a single Epic consisting of all the tasks, the downside, it's in a single project and that gets messy when doing quarterly planning sessions (based on Epics), as it wont show up in another's team Epic backlog. I usually tend to go with #1 above.

With both cases, there needs to be collaboration and agreement.

What are your thoughts?

[Warren]

Hi @Meytal BM 

Just answering at a high level and with respect to Agile, not Jira specific. The general rule is that you have ONE backlog per project, regardless of how many teams are working on that project. Now I know that the definition of "project" can vary and if it's a monster huge project you may opt to split it into more than one backlog.

Jira easily handles multiple teams working from one backlog, be it Scrum or Kanban. Handling dependencies isn't always quite that easy in any of the Agile software packages that I've used. At my previous company we used an Excel spreadsheet with a section per team - the key for success is to ensure that any teams involved with a dependency have a discussion and come to an agreement. Then review regularly so that no-one loses sight of the dependencies.