Board setup - one programme, multiple projects, multiple suppliers within each project

[kate_feeney]

I have a programme of work setup as a jira project

for each 'release' (using versioning), we are grouping user stories developed across multiple scrum teams

question i have is - how best to setup my board structure.

should use one sprint board with multiple sprints (to reflect 3 different suppliers in 3 different scrum teams developing concurrently). OR give each of them their own sprint board

pro to the second option (if I've understood jira capabilities) is that each scrum team has a distinct burn down chart 

con to the second option (multiple boards to administer).

note: each supplier will have to manage their own code release process but their will be dependencies and it may be that releases happen concurrently OR separately.

[francis]

You can also consider an approach where every supplier is using their own jira with their own configuration.

Using an issue sync tool, you can ensure that all the task related information is centralized on yours, such that you keep an overall overview of whats going on.

some issue sync apps are available on the marketplace 


We are one of these vendors (Exalate) which provides full sync capability of issue information, hierarchical sync of epics, stories and subtasks, worklogs, ranking, sprint specific information and so on.

If you would like to know more - welcome to book a demo here

[Ste Wright]

Hi @kate_feeney 

Parallel Sprints - which allows one board with multiple active sprints - will provide sprint reports per sprint much like separate boards would.

You can activate Parallel Sprints as a Jira Admin - go to:

1. Jira Settings > Products
2. Select Jira Software Configuration from the left-hand menu
3. Check the box next to Parallel Sprints

From a board perspective, this allows you to start multiple sprints concurrently, whilst still working from one backlog. Each sprint will still have a report - you can switch between sprints on the report using the drop-down in the upper-left corner.

-----------------

Whether this is the right approach is dependent on your setup - for example:

• Parallel Sprints: If you have one backlog and all suppliers have work which is populated from this, then one board with multiple concurrent sprints might work. However, this would rely on the board configuration (eg. status > column mapping) being the same for all teams
• Separate Boards: If each supplier has their own, specific backlog - then a separate board each might work better. This also gives the supplier greater flexibility over their board configuration (columns, quick filters, etc)
• Program Board: If you have a layer above the stories - such as Epics - you might consider tracking these in a separate Kanban Board. That way, you could track the overall progress of each larger group of issues, whilst tracking the supplier work in their own Scrum boards.

-----------------

I would consider the needs of both your team for centralised reporting and backlogs, versus whether each supplier works in a similar fashion or not and if they would require flexibility in their ways of working.

Ste