It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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. 

 

Like # people like this
Nic Brough Community Leader Jun 01, 2017

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

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.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Jira Software

Early Access: If you use Jenkins and Jira Software Cloud, you need to read this!

The Jira Software Cloud Team has been busy working on a simple, secure, and reliable way to integrate your build and deployment information from Jenkins with Jira Software Cloud. This means you don’t...

2,136 views 3 19
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you