structuring jira for multiple scrum teams and complex development

Question

I'm working on a global project that is delivering an application to multiple countries (not all at the same time) so require Release backlogs per country and have multiple scrum teams working accross each of the releases.

Based on this, I'm trying to assess how best to setup JIRA under the following scenario points:

* I want a product backlog that will never close - this will contain stories that will be duplicated for each country
* I need seperate release backlogs for each country OR
* we have 15 Scrum teams - they will each need a release backlog for the work they are engaged in accross countries
* I need to report on the progress to each country's completeness, not the project as a whole 
* Acceptance criteria may be different for each country.  I.e a global story may gave 4 acceptance criteria, but only 2 of those may be applicable to one country and the other 2 to another whilst all 4 may be applicable to a third country.

I am thinking that JIRA Portfolio is going to be an absolute necessity in order to manage this, but I would welcome any feedback that anyone has on structuring large complex projects with multiple releases across multiple scrum teams.

By way of background, we are assessing JIRA after using RTC for a number of years, where setting up hierarchies such as this are possible.

Robert Leitch [ALM Works] · Answer

Hello Rick,

I recommend taking a look at our Structure plugin (disclosure: I work for the company that develops it).

From your description of the task in hand, I can venture that Structure could help in the following ways:

* I want a product backlog that will never close - this will contain stories that will be duplicated for each country* This could be a single structure of issues (a 'structure' is a collection of issues of any type, from any projects) that could be copied (cloned) into other structures for each country. From there you can decompose them into tasks that may be different from those required in other countries' backlogs.

Alternatively you might not need to clone it - just pull in the required issues to each country's backlog structure. The limitation here would be that each issue has a common workflow.

* I need seperate release backlogs for each country OR* A separate backlog structure for each country, their contents can be retrieved in Scrum boards using S-JQL (an extension to JQL that allows you to query the contents of structures).

* we have 15 Scrum teams - they will each need a release backlog for the work they are engaged in accross countries* Same as above.

* I need to report on the progress to each country's completeness, not the project as a whole * Easily done by adding a progress column to the country backlog structure and adding all its issues to a folder. Progress can be reported according to time spent, workflow statuses (assign a custom progress to each status, e.g. Open = 0%, In Progress = 50%, etc.), story points, etc.

* Acceptance criteria may be different for each country.  I.e a global story may gave 4 acceptance criteria, but only 2 of those may be applicable to one country and the other 2 to another whilst all 4 may be applicable to a third country.* We also have a free extension, Structure.Testy, that could assist somewhat with this.

Sorry if that sounded too much like a sales pitch. I hope it makes sense (it's less complicated than I make it sound) and meets your needs in some way. Feel free to drop me a line on robert@almworks.com if you'd like to discuss in more detail.

Chris Dunne · Answer

You will probably want to look at filters for this.

You could create a custom field for Country and show this on the backlog by configuring the board and its card layout.

You could create boards for each country and the filter for these boards would only show stories for that country.

You could also create boards for each scrum team that will combine all stories across countries that are allocated to that team.

Portfolio for JIRA might also help here. I don't really know how acceptance criteria could be managed.

Chris