Multiple teams delivering a single product through one Jira board X4

Question

Hi,

my company is delivering 4 products (1 main and 3 additional, smaller ones) with many features that are being worked on by the same 4 teams. Also, the teams have many repositories they need to connect to within a single product. Ideally, we would want to have only one board per product:

- can we connect a single board to multiple repositories (i.e. have multiple target repositories to which we can commit code separately (e.g. I want to push something to 1 specific FE repo, but I don't want to touch any of the other FE repos or BE repos))

- can we have a single sprint for everything (all products, all teams) that everyone can see

- can we "collect" issues that are done and then release them to production in bulk

- can each team have access to the same backlog or do they have to have separate ones to be able to create new issues and assign them on their own

This might be a tall order, I'd appreciate any help.

Dick · Answer

Hi Sven, 
Sorry to have kept you waiting (I've been on a small vacation).

You can harness all your issues in one project, with the component as a discriminator for four boards. The jql for each of the boards would be like:

Project = (MainProject and issuetype is epic ) or (MainProject and component = X  )

For each board, you could have all the epics to see, together with a sub-set of the stories for each component.

With only one project, sharing a sprint would be possible. You could even make an overall board where you use swimlanes based on the component value.

Overall, I think that one project for the whole lot should be the best solution for your case.

Sven Sesvecan · Answer

hi Dick, thanks for the fast response. I will look into components, it seems like it's the way to go. What you said about repositories, how does that affect triggers in a workflow? Can we still set them up so auto pull/push occurs when switching between statuses?

My initial plan was basically to create one backlog for one project and give access to it to every team so we could manage everything from one place, but it looks like that's not sustainable (am I right?). The reason behind that plan was that the way they used to do it (one project per team) became a horror story from an admin/management point of view.

We might be talking about the same thing, but the other way I thought of was creating one backlog for one project, which would translate into one main Scrum board. From there, I'd create a Scrum board for each specific team and then create filters that would allow those team boards to see the main board's stories (and their parent issues) and share the same sprint. Basically they would then share the backlog, see stuff specific to them and be able to manage themselves (create subtasks based on stories, assigning them within their teams etc.) - would that in any way prevent us from creating those multiple repo targets I talked about? or a specific team's ability to create (sub)tasks, move them and resolve them?

Dick · Answer

Hi Sven,
I would use components to distinguish between products and projects for each team to have work in.

Issues are connected to commits in GIT repositories. So yes, if we collect multiple issues in a board, we can have multiple repositories "connected" to the board.

One board per product is achieved by having the board filter for a specific component that might be used in all your projects, similar to:

* project in ( A, B, C, D) and component = "X"

Releases would go per project and the backlog would be per team/project to create issues in and assign them on their own (you were on the money on that one :)  )