Multiple boards, backlogs, tickets under same project

[Adrian Munteanu]

Hey folks,

Need your help to understand if what I am after is possible:

Current: as a product owner, I own multiple products, for which I am running separate sprints, with their own cards, where I can give my developers permissions to view and edit the cards.

Desired: I want to have under the same structure (let's say a project named after the area I am leading), under which I want to have all my products' boards, with their issue type names, separated on different backlogs specific for every product and accessible only by the assigned developers. Tried with classic project and so far was able to accomplish the followings:

created a project called TOM, under which I have been able to create following different boards: KLARA, CBS, Shotgun, WebApps. Related to these boards, I have also created various Story types for every of these products/boards. The first problem I have is that all cards inherited the Project name and they're all named like TOM-xx. Could that be customized?

Also, checking the backlog for various boards I have created under TOM project, all cards are showing, regardless of the board I am choosing. How can I see them on separate backlogs, related to the boards I am choosing?

Also, presuming that above would be possible, how can I separate accesses of developers per boards?

Thanks,

Adrian

[Trudy Claspill · Accepted solution]

Hello @Adrian Munteanu 

Welcome to the community.

First, let me clear up a concept.

Issues exist in projects, not in boards. Projects are the containers for issues. Boards are just a way to visualize and manage the issues. You do not create issues in a "board"; you create issues in a project and the board is configured to view issues in 1..n projects.

You cannot customize the ID assigned to issues - the XYZ-123 identifier. This is going to pick up the key for the project in which the issue exists, always.

You can create boards that show a subset of the issues in the project by customizing the filter used by the board. You would need to have something in the each issue to identify which board it should display in, like a unique Component or Labels value, or you may choose to have a totally separate custom field for that. Then you would modify your board filters to include a criteria for that field/value. Note you would want to include also the criteria for the field being empty, so that the card would show up on all boards until it is properly tagged;

example:

project=TOM and (Component="CBS" or Component is empty)

Separating the access for developers to be able to view and modify the cards only for their "board" is more challenging. Permissions are generally set at the Project level. While you can limit who can view your board by limiting with whom you share the Filter used by the board, the developers would still require View and Edit permissions in the underlying project where the issues exist. And allowing them to view and edit only a subset of those issues would be very challenging to implement.

If you truly need your developers locked out of the boards for other products, then you should separate the issues into Projects based on the products, and boards per project. 

[Adrian Munteanu]

Hey Trudy,

Thanks for the message. Actually I already have the setup like you recommend, each product using its own project space. I was thinking if I can have everything organized under the same "umbrella" which would be the area I lead.

Is there a way to achieve that?

Thanks,

Adrian

[Trudy Claspill]

What are you trying to achieve by organizing different products under one "umbrella" based on you being the product owner? Is this something that is needed by the other product owners in your organization?

How has having the products tracked in separate projects hindered you?

If you explain what you are trying to achieve, we might be able to suggest an alternate method.

[Adrian Munteanu]

Basically there is no connection between CBS, Shotgun, Klara and WebApps Projects and there should be, as they're all under the area I am leading. Under each of this project, the CRs are having their own project inherited identifier: CBS - xx, SG-xx etc. And that is fine. Just that I want to link them all somehow.

Bottom line: I want to carry on like I am doing right now, in terms of the way I am running sprints and permissions I assigned my developers. I just need them all to be under one area: TOM. 

Is there any way to achieve this?

[Trudy Claspill]

Hello @Adrian Munteanu 

What are you trying to achieve by "linking" them, when you want to keep the permissions segregated, keep separate boards, separate sprints, and want separate issue IDs?

There must be a reason for you wanting this. Are you trying to generate some sort of report? Are you wanting to be able to view all the work of the disparate teams in one board, just for yourself? 

In my first response I discussed the challenges you would face with trying to limit the permissions of the various product teams to only their issues if you try to put all the work into one project. Is it possible? Maybe. Is it advisable. No, not in my opinion.

If you can explain exactly why you want to do this, it will help us answer your question more effectively.

[Adrian Munteanu]

It is more like the way I organize my area, but also pulling reports could be also useful.

But mainly, most annoying for me is the fact, above Project entity, couldn't find a way to have these projects linked somehow.

Clearer?

[Trudy Claspill]

You are correct that there is no way to "link" projects to each other. 

Most reports are based on filters. You can construct filters that pull data from multiple projects. If there is a specific report you are trying to generate for which you are having trouble, post a message about that scenario.

I am hearing that you want to keep the products and teams segregated and you will specifically have difficulty doing that if all the issues are in one project.

I'm not hearing from you about a specific problem that you are trying to solve that you think can't be solved with separate projects and can be solved by a single project. You said it is "annoying" that you can't link projects together. Exactly what is annoying about that.

I am sorry that I keep coming back to that, but what problem are you trying to solve, specifically? Putting all the data in one project is going to create difficulties and challenges for administering the project and could result in your product teams erroneously affecting the information for another product team. Keeping the data in separate projects lowers the risk and does not increase administration work, but is an annoyance to you.

It seems like the better scenario is to keep the product teams using separate projects.