How to organize Jira for Multiple Projects/Team & Multiple Teams/Project

Erik Yeargan November 14, 2013

Hi Guys,

I'm a ScrumMaster at a company that has 4 specialized dev teams and several projects running at any given time. Each project might have components for more than one team, based on their specialities.

So, Project Owners need to manage their project backlogs & assign work to different teams as needed. Then those teams need to manage ONE board with all the Stories assigned to them, often from more than one Project.

There MUST be a case study somewhere with the Best Practice method for doing this.

Thanks!

Erik

3 answers

8 votes
Sam Arundel December 3, 2013

This is a workflow, as far as I can tell, for one project worked by more than one team. I need help with the other scenario - my dev team works several projects. Particularly, we have a huge project that has resulted in a piece of software. We set up a JIRA space for that project. Now what I find is that my developers are being asked to do some extraneous, but very related work, but it is not part of this original software. Should I have a different JIRA space for the new work, or just another board? But then my developers have to look at more than one board to see their work and mark what is in progress/resolved, etc? I really don't want them to have to do that.

Thanks!

Sam

SilverPr June 1, 2017

Hi

The way we managed to scale it is: 
We devided persons by their area of expertise into "micro-teams" They all are sitting within the same Jira project (Lets say Jira project A). All the micro-teams have their own scrum board therefore their own backlog and sprints. So Jira project A has many boards: Scrum board for Team 1, Team 2 and Team 3. And we also have a Kanban board for Jira Project A. 
Now the idea is that we have all the workflow statuses alligned in between all the boards. (You can add more statuses if You like) so in principle if I have issue moved from "ToDo" to "InProgress" it will show correct status in every board. Now to show all items in kanban board and only team 1 items in Team 1 scrum board: We use labels. Meaning we use our kanban board to label issues per team and our microteam scrum boards are configured to show only issues with label: Team_x.
If PM who is sitting in his own Jira project (Jira Project B) wants to create and keep track at issues in Jira Project A (or even C and D etc.) He needs to create his own board (and make it private) and configures the board to show data from Jira project A,B,C,D and with label PM_1 ; and also making sure that the workflow statuses are alligned (or configured in a way that his columns will show statuses used other Jira projects) Now PM creates issues to different Jira projects and labels them with PM_1 and have them all visible in his board and can keep track how they will progress in other Projects/teams. without the possibility to move issues (change statuses) in other projects. 

 

Like # people like this
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 1, 2017

Bear in mind your solution is for more recent versions of the systems - the original question is 4 years old.

Gabriel Landowski August 20, 2018

But it helped!

Like Heather R likes this
Rabih Kraidli December 31, 2019

@SilverPr so you're sprints are created only in the boards of Project A?

Nicolas Fernström December 18, 2020

We use the same solution, and yes, the sprints are created on the project where all the team boards are created. 

In other words, we have a "Teams" project with one board for each team and then we have product oriented projects which are used to collect requirements for a specific product. Every issue is linked to a Team through (in our case) a custom field called "Dev Team". 

Would have been smoother if you could somehow link issues with Jira Teams, but that doesn't seem possible at this stage. 

0 votes
Erik Yeargan November 14, 2013

I have recently see this post that SEEMS to answer my question, but it also includes and UPDATE that suggests the solution is no longer valid.

Shaun, can you clarify this for us all?

Tao Klerks · 151 karma · Sep 20 '12 at 11:23 AM

Turns out my test case was too complicated.

Greehopper has no problems with multiple "Boards", with different filters, running sprints in parallel, within the same project.

What made it refuse, in my case, was that my filter was showing a particular issue in both boards, and therefore that issue was showing up on an in-progress sprint even on the board of the team where I wanted to start another sprint.

Bottom line: as long as the filters on your boards are mutually exclusive, it will work just fine!

(in fact, it's even nicer than that - if you do start two sprints in parallel on separate mutually exclusive boards, then any "overarching" boards will show you all the sprints that are in play according to that board's filters. Similarly, the reporting seems to show you data for issues that match the filters of your Board - even if those are a superset or subset of other boards. It's really rather lovely! :) )

UPDATE: I originally used "Label" as the basis for the filtering, but this was a problem for a Scrum workflow because the technical tasks (created during sprint kickoff) didn't inherit this field automatically; the "Component" field, on the other hand, is inherited by default so is a much better choice.

UPDATE - PROBLEM WITH THIS FLOW (Temporary, hopefully): The latest version of Jira Agile breaks the flow above, because it allows the "Start Sprint" feature to include stories that were included in the sprint in some higher-level planning board, without the knowledge of the team that IS actually starting the sprint. Those invisible stories then show up in that team's sprint, gunking things up on all levels (reporting, etc) and can't be cleanly resolved, as they show up in the committed numbers of that sprint.

0 votes
Erik Yeargan November 14, 2013

I have recently see this post that SEEMS to answer my question, but it also includes and UPDATE that suggests the solution is no longer valid.

Shaun, can you clarify this for us all?

Tao Klerks · 151 karma · Sep 20 '12 at 11:23 AM

Turns out my test case was too complicated.

Greehopper has no problems with multiple "Boards", with different filters, running sprints in parallel, within the same project.

What made it refuse, in my case, was that my filter was showing a particular issue in both boards, and therefore that issue was showing up on an in-progress sprint even on the board of the team where I wanted to start another sprint.

Bottom line: as long as the filters on your boards are mutually exclusive, it will work just fine!

(in fact, it's even nicer than that - if you do start two sprints in parallel on separate mutually exclusive boards, then any "overarching" boards will show you all the sprints that are in play according to that board's filters. Similarly, the reporting seems to show you data for issues that match the filters of your Board - even if those are a superset or subset of other boards. It's really rather lovely! :) )

UPDATE: I originally used "Label" as the basis for the filtering, but this was a problem for a Scrum workflow because the technical tasks (created during sprint kickoff) didn't inherit this field automatically; the "Component" field, on the other hand, is inherited by default so is a much better choice.

UPDATE - PROBLEM WITH THIS FLOW (Temporary, hopefully): The latest version of Jira Agile breaks the flow above, because it allows the "Start Sprint" feature to include stories that were included in the sprint in some higher-level planning board, without the knowledge of the team that IS actually starting the sprint. Those invisible stories then show up in that team's sprint, gunking things up on all levels (reporting, etc) and can't be cleanly resolved, as they show up in the committed numbers of that sprint.

Suggest an answer

Log in or Sign up to answer