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

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

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.

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.

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

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. 

 

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

Suggest an answer

Log in or Join to answer
Community showcase
Teodora [Botron]
Published Thursday in Marketplace Apps

Jira Inferno: The Nine Circles of Jira Administration Hell

If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...

481 views 1 15
Read article

Atlassian User Groups

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!

Find my local user group

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

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot