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

Erik Yeargan

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

Erik Yeargan

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.